Support for `${env:ENV}` syntax

[mx-psi]

The Collector supports ${env:ENV} style syntax in addition to ${ENV} and $ENV. It would be desirable that the Collector and the SDK configuration files support the same syntax.

The Collector SIG has previously discussed dropping the $ENV syntax, and there seems to be consensus for it. While this needs to be explicitly discussed, I think we are willing to support ${ENV} as a shorthand for ${env:ENV}.

To align the two configuration formats, I would like to ask the Configuration WG to do one of the following:

1. Support the ${env:ENV} syntax as equivalent to ${ENV} OR
2. Explicitly fail when the ${env:ENV} syntax is present in a configuration file

Since the environment variable names accepted by the current specification are ASCII alphanumerics + _, there is no ambiguity with the ${env:ENV} syntax. However, we need to make a decision now on this (while experimental), since resolution would work differently.

[jack-berg]

For context, here's the discussion on this topic from when env var substitution was initially added.

We discussed in the 11/21/23 spec sig. Meeting notes entires on the subject:

Options:

• ${env:MY_VAR}
  • Aligns with collector
  • Exposes collector provider concept which file configuration WG does not (currently) want
• ${MY_VAR}
  • More familiar syntax
  • Collector would need to un-deprecate this syntax and use it as alias for “env:” provider
  • Evolvable to ${env:MY_VAR} syntax if we later determine we need provider concept
• (josh) Alternative: {{MY_VAR}}
• Don’t want to support provider concept in file configuration because simpler syntax promotes more implementations of file configuration
• Small group seems to agree on simpler ${MY_VAR} syntax. Reasons:
  • More familiar syntax
  • “Env:” prefix suggests that other providers are possible.
  • Can always come back and change later since this is experimental.

So the pushback was about not wanting to burden implementations with the complexity of having to implement other env vars substitution sources besides env vars, and to have a syntax for familiar to bash users.

I think that alignment with the collector syntax is a good reason to accept the ${env:MY_VAR} syntax as an alternative, as long as its not also a call to support additional providers. For the time being, we should priority simplicity and portability across language implementations. Adding additional providers should be supported by strong user feedback.

[trask]

cc @open-telemetry/configuration-maintainers