Add support for instrument-specific metric tags in the incoming pipeline

[tmasternak]

Based on https://discuss.particular.net/t/adding-custom-tags-values-to-nsb-metrics/4631

Requirements and Constraints

The PR lets a user customize the tags NServiceBus Core attaches to the meters it publishes: adding new tags, removing ones Core sets by default, and modifying values already present. Today the tag set is fixed by Core, so nothing application-specific can reach the metrics.

Constraints

• Minimize public API surface — Every new public type or member is a permanent semver commitment, so the design should expose the smallest thing that delivers the capability. This is what disqualifies shipping internal state objects as API just because they happen to be reachable.

• Reuse OpenTelemetry's API surface — Where OTel or System.Diagnostics already defines a concept (tags, instruments, TagList), use it rather than inventing an NServiceBus-shaped equivalent. Users already know that surface, and parallel abstractions age badly.

• Per-instrument, from inside the pipeline — A user must be able to set different tags on different instruments, and to do it during pipeline execution where the message context is available. This is the hard requirement: a design that applies one uniform tag set everywhere, or that runs outside the pipeline with no access to the message, doesn't solve the problem.

Decisions

• Public API invoked from inside the pipeline — Customization is done by calling a public API from a pipeline behavior, keyed by instrument name. Being inside the pipeline is what gives access to the message context that makes a custom tag worth setting; keying by name is what lets tags vary between instruments.

• IncomingPipelineMetricTags becomes internal — It stays in Core but leaves the public API surface, because the concrete class carries per-instrument storage, ApplyTag/ApplyTags that only Core calls, and TagList plumbing. Removing it from the public API isn't a SemVer-breaking change, as it was never documented and used only in Testing.Fakes.

• IMetricsTags is the public API — A single interface in the NServiceBus namespace with one member, void AddOrOverride(string tagKey, object value, string instrumentName), implemented by the now-internal class, and returned by ContextBag.MetricTags. The message-wide Add(tagKey, value) overload is deliberately internal — only Core seeds message-wide tags (queue, discriminator, message type, handler types).

• internal accessor for Core's own use — Core's recording code reaches the concrete collection through a second, internal extension property ContextBag.IncomingMetricTags in the same extension block. That keeps ApplyTag/ApplyTags out of the public API without forcing a cast at every call site.

Rejected Solutions

• Tags derived from the ambient Activity — Reading Activity.Current's tags at record time and projecting them onto the meter scores well on both principles (almost no new API, pure OTel reuse), which is why it keeps resurfacing. It fails twice: the ambient activity isn't under our control, so a customer replacing Activity.Current makes the tags unpredictable, and it offers no way to vary tags by instrument name.

[ramonsmits]

Lets further discuss next week