Advice/hint APIs should be applied to all signals (when applicable)

[lmolkova]

From #3546 (comment)

What are you trying to achieve?

Some advice/hint API we have/considering adding on metrics could be as well applied to traces.

Examples:

• specify known valid values - Add metric advice to capture only a specific set of values for a given attribute, and normalize the rest to a value which represents "other" #3545
• normalize/sanitize attribute value (e.g. remove sub-domains from server.address) - feat(http-instrumentation): allow filtering of host name on metrics opentelemetry-js#3880
• drop verbose attributes (e.g. server.address not being helpful on server side) - Address high-cardinality attributes server.address and server.port attack vector semantic-conventions#108

When designing metric-only APIs, we can end up with:

• inconsistent telemetry on signals and limited attribute-based correlation
• inconsistent advice/hint APIs across signals and subpar dev experience configuring SDK

Additional context.

The suggestion is to tie advice/hint API with configuration efforts and ensure consistent in-code and no-code configuration across signals.

[mateuszrzeszutek]

I think that this is a great idea that's definitely worth pursuing -- I think the general advice API would make a great tool for opting in or out from collecting attributes (the server.* case I mentioned in #3546, server.socket.* attributes on HTTP server spans, url.query if it contains sensitive info, etc) + all the use cases mentioned above.

The advice API on its own does not achieve much though: it only works so well in metrics because we have the views API that users can utilize to override the instrumentation authors' recommendations. If we were to add advice API for spans/logs we would probably have to introduce some sort of views API for them as well (together with selectors for instrumentation scope).