Rename Optional attribute requirement level to Opt-In

[trask]

Fixes #3227

Changes

Renames "Optional" attribute requirement level to "Opt-In", to better reflect it's meaning.

For non-trivial changes, follow the change proposal process and link to the related issue(s) and/or OTEP(s), update the CHANGELOG.md, and also be sure to update spec-compliance-matrix.md if necessary.

[Oberon00]

Copying my comment from open-telemetry/build-tools#135 (comment):

There is actually a definition of our "optional" requirement level that says it's "opt-in": https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/attribute-requirement-level.md#optional

Optional

Instrumentations SHOULD populate the attribute if and only if the user configures the instrumentation to do so. Instrumentation that doesn't support configuration MUST NOT populate Optional attributes.

opt-in was also the original name this was proposed with in #2522 by @lmolkova, but @bogdandrutu requested reanaming it to "optional" in #2522 (comment):

I would actually consider to change "Opt-In" to "OPTIONAL", and say that instrumentation plugins must offers way to "opt-out" for any recommended attributes, and to "opt-in' for any available "optional" attributes. the required and conditional required cannot be disabled, this way we separate the 2 concerns about what is available and what is configurable for the user.

Personally, I would also still find "opt-in" clearer than "optional"

[Oberon00]

You need to also change the definition at https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/attribute-requirement-level.md#optional

[bertysentry]

I concur with @Oberon00: When specifying semantic conventions, we need to have different nuances for specifying the requirement (or not) of an attribute:

• Required (e.g. a unique ID)
• Recommended (e.g. a name, human-readable)
• Optional (e.g. extra information about the observed resource, not necessary to identify it, but helpful)

For Recommended and Optional, we could have a separate qualifier (e.g. Opt-in and Opt-out) which indicates whether this attribute can be enabled or disabled manually by the user (e.g. an IP address, a local file path, etc. for security reasons).

[Oberon00]

I concur with @Oberon00:

I wasn't suggesting to add an additional opt-out level. I think that's too fine grained and you should decide between "recommended" and "opt-in". I actually concur with this PR which stays with our current number of levels and just renames the "optional" level to better match its definition.