Make env config TLS disabled field optional

[THardy98]

What was changed

Made the TLS disabled field in env config Optional, to reflect it's tri-state:

• true -> explicitly enabled
• false -> explicitly disabled
• None -> not configured

Added a few tests for better e2e coverage

Why?

This representation mimics the TOML configuration when serialized, where as before, disabled would be serialized even if it wasn't set in the TOML config.

[cretz]

IIRC, the default of TLS (i.e. neither true nor false) was that it was implicitly enabled if there was an API key present, otherwise implicitly disabled. I think we need to respect that behavior in the SDKs (IIRC, Go does).

[THardy98]

that is the behaviour of this function, we only return False (instead of a TLSConfig) if disabled is explicitly enabled

[THardy98]

or are you saying that if a user supplies an api key AND sets disabled to explicitly true, that the api-key would take precedence?

[THardy98]

For example, this case:

        """
        [profile.default]
        address = "{target_host}"
        [profile.default.tls]
        disabled = false
        server_name = "my-server"
        """

technically, TLS is enabled here, there's no restriction as long as don't set disabled as true. We'd basically pass an empty TLSConfig to the client on the connect call

[THardy98]

the test in this commit lays out the various cases:
9423e82

[cretz]

The issue actually is at to_client_connect_config. So if ClientConfigProfile.api_key is present CleintConfigProfile.tls is None, does tls get enabled? It doesn't seem so from the code, but it should.

[THardy98]

This is done in core:

  /// Apply automatic TLS enabling when API key is present
  pub fn apply_api_key_tls_logic(&mut self) {
      if self.api_key.is_some() && self.tls.is_none() {
          // If API key is present but no TLS config exists, create one with TLS enabled
          self.tls = Some(ClientConfigTLS::default());
      }
  }

though now, given that we have logic in lang to transform to/from object that should represent the TOML, this may no longer be desired/accurate.

Probably the best solution here is to change pub tls: Option<ClientConfigTLS> in core to:

pub enum ConfigTlsEnum {
    Enabled(bool),          // TLS enabled, default options (i.e. api key but no tls)
    Config(ClientConfigTLS), // TLS explicitly configured
}

and then:

pub tls: Option<ConfigTlsEnum> // null is no api key or TLS configuration

alternatively, we keep core as is and make the change upstream in the bridge, with the logic being something like "if received TLS object is ClientConfigTLS::default(), then transform to true"

or we remove apply_api_key_tls_logic from core altogether and have lang implement this logic

[THardy98]

I am leaning towards the latter, will open a PR

[THardy98]

latest commit covers this case