[confmap] Use original string value on expansion

[mx-psi]

Description

Originally on the env var RFC I proposed using the YAML parsed value when parsing a string, which has been the default behavior until now of ${env:ENV} and friends.
An alternative is to use the raw string value, which is what ${ENV} used to do. The difference (after enabling strict types) does not matter much in practice save for a few edge cases (since strings can be represented in multiple ways), namely on the YAML parsing scenario:

• Quotes get removed ("opentelemetry" -> opentelemetry)
• YAML type tags get removed (!!str opentelemetry -> opentelemetry)
• Literal newlines get removed (although this may be a bug in our parser, see Chomped literals with multiple newlines lose a line-break after a roundtrip go-yaml/yaml#963)
• Escaping sequences are mapped to their own character

It's a matter of opinion which behavior is more intuitive to end users. In this PR I change the behavior to use the raw string value. I think the arguments in favor are:

• It's arguably less surprising (you get what you wrote)
• It solves a real issue faced by an user (see below)

Link to tracking issue

Fixes #10405 (comment)

[mx-psi]

This change is under the strict types gate

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.26%. Comparing base (3087c53) to head (56e9577).

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #10603   +/-   ##
=======================================
  Coverage   92.26%   92.26%           
=======================================
  Files         395      395           
  Lines       18703    18705    +2     
=======================================
+ Hits        17257    17259    +2     
  Misses       1086     1086           
  Partials      360      360           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[TylerHelmuth]

This breaks users right?
If I entered endpoint: "http://localhost:4317" instead of my exporter using http://localhost:4317 would it attempt to use a value that contains double-quote literals?

[mx-psi]

If I entered endpoint: "http://localhost:4317" instead of my exporter using http://localhost:4317 would it attempt to use a value that contains double-quote literals?

That would happen if you did

endpoint: ${env:ENDPOINT}

with ENDPOINT set to "http://localhost:4317" (quotes included). The changes only affects how the values passed via a provider are parsed

[mx-psi]

If we were to do this we would have to sync with the OpenTelemetry Config WG to see how this lines up with their behavior. I am still not sure if this is a good idea or not

[TylerHelmuth]

This changes the behavior when the feature gate is disabled. Before it would set the string representation to be the yaml parsed version of the string (so \n is removed.

[mx-psi]

Yup, but the string representation is only used under the strict types feature gate, so it's also under a feature gate

[TylerHelmuth]

Let's add a row for foo\nbar

[TylerHelmuth]

Add foo::

[mx-psi]

I have been mulling over this over the weekend and I don't think this is a good idea, since it completely prevents users from escaping content to say "this is a string". A better solution would be to preserve the original string value and use it while unmarshaling with a decoding hook if the target field is a string. I have tried and failed to implement this (not saying it can't be done, but it's definitely messy to do)

[mx-psi]

#10618 is a more complex but more sensible version of this

[mx-psi]

Closing this in favor of #10618