Rename "advice" to "advisory parameters"

[dashpole]

Fixes #3621

Changes

• Change advice to advisory parameters. The intention is to change advice from implicitly being a concrete parameter to being a category of parameter.
• Add advice/advisory parameters to the Asynchronous Instrument API (which I believe was an oversight). It is currently only part of the Synchronous instrument API.
• Clarify that what makes "advisory parameters" different from other parameters is that implementations may ignore them.
• Consistently use "parameters" instead of "fields" in the API

@jack-berg @jsuereth is this something like what you had in mind? Some alternative approaches we could consider if we want to keep "advice" as a noun:

• Keep "advice" as a noun, but add flexible language e.g. "advice can be omitted in favor of the underlying parameters"
• Keep "advice" as a noun, but describe it as a category of parameter.

[reyang]

• Change advice to advisory parameters. The intention is to change advice from implicitly being a concrete parameter to being a category of parameter.

Why not using "hints" (which was the original name that we've been using during the discussion)? @jack-berg

• Add advice/advisory parameters to the Asynchronous Instrument API (which I believe was an oversight). It is currently only part of the Synchronous instrument API.

+1

[MrAlias]

Why not using "hints" (which was the original name that we've been using during the discussion)? @jack-berg

It would need to be "hints parameters" still to indicate that these are a category of parameters, right?

[dashpole]

Why not using "hints" (which was the original name that we've been using during the discussion)? @jack-berg

I don't think that would address #3621, as it is still a noun, which implicitly is a parameter. "hint parameters" would work, but I don't have a strong opinion on advice/advisory parameter vs hint/hint parameter

edit: tyler beat me to it

[reyang]

Why not using "hints" (which was the original name that we've been using during the discussion)? @jack-berg

It would need to be "hints parameters" still to indicate that these are a category of parameters, right?

I was thinking about SDK View https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/sdk.md#view.

The SDK MUST provide the means to register Views with a MeterProvider.

Whether Views are provided as a single argument or multiple arguments is up to the implementation. Hints can be handled using the same way.

[reyang]

Why not using "hints" (which was the original name that we've been using during the discussion)? @jack-berg

I don't think that would address #3621, as it is still a noun, which implicitly is a parameter. "hint parameters" would work, but I don't have a strong opinion on advice/advisory parameter vs hint/hint parameter

See my reply here #3662 (comment). Another thing to consider - do we want to stop folks from using a single parameter for all advice/hints? I don't see a strong reason why we want to have such preference.

[jsuereth]

The only piece of this I'm not sure whether or not it's missing is the bit @jack-berg / @MrAlias were discussing regarding having a firm description of which advice to accept in the event you have two registration events with conflicting advice (i.e. the whole first-seen-by-runtime verbage). You may have it in this PR and I missed it, or it's covered by some other section of the spec and I also failed to recall. Just want to make sure that's covered.

[dashpole]

having a firm description of which advice to accept in the event you have two registration events with conflicting advic

That was done in #3661.