refactor(stackable-telemetry): Support Option<T> in subscriber methods

[Techassi]

Part of stackabletech/issues#639

As requested in #901 (comment), this PR enables this:

.with_otlp_log_exporter(
  otlp_log_flag.then(|| Settings::builder()
    .with_environment_variable("ABC_OTLP_LOG")
    .with_default_level(LevelFilter::INFO)
    .build()
  )
)

[nightkr]

Any reason to implement this toggle separately for each variant, instead of just reusing Option<ConsoleLogSettings>?

[NickLarsenNZ]

Yes, to abide by the orphan rule - because of impls we needed:

impl<T> From<Option<T>> for BlahSettings
where
    T: Into<BlahSettings>,
{ ... }

[NickLarsenNZ]

Or did you mean providing something like:

pub struct GenericSettings<T> {
  Disabled,
  Enabled<T>,
}

// where T could be Settings or ConsoleSettings, OtlpTraceSettings, etc...
impl<T, U> From<Option<T>> for GenericSettings<U>
where
    T: Into<U>,
{ ... }

then

pub struct ConsoleSettings {
  ...
}

[nightkr]

Ideally I'd avoid the From entirely; with_file_output takes an Option<FileLogSettings> and that's that. But I understand if that's too extreme, or if that ship has sailed already...

As a compromise, we could define our own trait with a blanket impl:

trait IntoLogSettings<S> {
    fn into_log_settings(self) -> Option<S>;
}
impl<T: IntoLogSettings, S> IntoLogSettings<S> for Option<T> {
    fn into_log_settings(self) -> Option<S> {
        self.and_then(|x| x.into_log_settings())
    }
}