Inconsistent hierarchy and naming between MeterRegistry.Config and MeterRegistryConfig

[climategadgets]

Describe the bug

• Most registry constructors have an argument named config of types that are ultimately inherited from MeterRegistryConfig;
• MeterRegistry has a method named config().

Expected behavior
According to the Principle of least astonishment, it is expected that MeterRegistry.config() will return the same object that is provided to the constructor.

Actual behavior
MeterRegistry.config() returns an object of class MeterRegistry$Config that has nothing to do with configurations inherited from MeterRegistryConfig.

Additional context

• MeterRegistry$Config and MeterRegistryConfig are not navigable from each other
• It is not possible to retrieve the configuration submitted to subclasses of MeterRegistry, this hinders troubleshooting, especially in environments with complex autowiring happening in third party dependencies.

Desired resolution
Make MeterRegistryConfig and MeterRegistry$Config either belong to the same hierarchy, or at least make MakeRegistryConfig subclasses navigable from meter registry instances available via introspection.

[jonatan-ivanov]

I think this is intentional but I can see that the similar name might be confusing:

• MeterRegistry$Config configures how your data is recorded (user-facing part of the registry)
• MeterRegistryConfig configures how you export the recorded data (backend-facing part of the registry)

We cannot really change this in 1.x I think but let's leave this open to see if we can get more feedback and in case we will release 2.x.