4.x metrics app name tag fix

[tjquinno]

Description

Resolves #9664

The fix for the main bug exposed another problem (see below) which this PR also fixes.

The main fix

Synopsis: Helidon failed to correctly provide in SE the tag to be used for conveying the app name if the user specified an app name in the config (but not explicitly the tag name to use).

Details:
Metrics has a MetricsProgrammaticConfig interface which is primarily a way for SE and MP to dictate config settings in the MetricsConfig type. (Even if the user sets them, the implementations of this interface override those settings.) Among other things, this type allows control over reserved tag names, the tag name used to convey the meter's scope, etc.

The pre-existing MP implementation is fine. There was no SE implementation, relying on (incomplete) default behavior defined in the interface itself.

This PR introduces, for clarity as well as the bug fix, an explicit SE-specific implementation. It is always consulted, but if the MP one is also present the code runs it last, overriding anything the SE implementation might have assigned.

These implementations are invoked when the MetricsFactoryManager is invoked with a MetricsConfig instance to prepare a MetricsFactory (which, ultimately, instantiates a MeterRegistry which is where some of the settings go into effect.) There is a slight change in that class where it collects the MetricsProgrammaticConfig instances to apply them so that the MP implementation supersedes the SE one.

The other problem: recursive infinite loop exposed

Synopsis: SystemTagsManagerImpl is initialized by MetricsFactory, and during its initialization it would invoke MetricsFactory which would attempt to re-initialize SystemTagsManagerImpl, and around we go.

In metrics, the MetricsFactory is a gateway to many operations whose implementations depend on the underlying metrics provider (Micrometer is the only one so far). In obtaining an instance of this type, the system also prepares an instance of SystemTagsManager. One responsibility of that type is to provide a collection of Helidon Tags containing whatever tags should be applied to all meters created.

Before this PR, that code would prepare the Tag collection during initialization. The latent bug (hidden by the main bug) was that this initialization code would invoke Tag.create (on the Helidon-neutral Tag interface) which has to ensure that the tag names from the caller (usually the app developer) do not conflict with the reserved tags, which in turn would need to access the MetricsFactory which was currently being initialized so the LazyValue holding it was still empty...triggering a recursive construction.

The fix to this bug is to store a Map<String, String> for the universal tag names and values during initialization and only manufacture Tag instances upon first real need...after initialization has completed. This new map removes the need for the separate systemTagNames set (because it can be derived from the key set of the new Map<String, String>.

There was one other bit of code that referred to the instance() method instead of the instance parameter which caused a separate recursive infinite loop, also fixed.

Documentation

No doc impact.

[ljnelson]

Should this be unmodifiable?

[tjquinno]

What would this being unmodifiable protect against? The returned Map does not use the original for backing.

[ljnelson]

True enough. Although without the unmodifiable contract, then it is OK for any caller to do, for example, something stupid like stm.displayTagPairs().clear(). Obviously that's their problem, not yours, but it's part of the contract. (The alternative is documenting that it will throw an UnsupportedOperationException if a mutation is applied to the returned Map.)

[ljnelson]

A copy? Or would an unmodifiable view suffice?

[tjquinno]

No need for a copy here. Changed.

Similarly changed displayTags() which also does not need a copy but can instead returns an unmodifiable view.