add copy() method to Builders

[qweek]

Summary
This PR allows to reuse builders as templates for dynamic tags, factories, etc.

Changes
Introduce additional copy() method in all specific Meter's Builders, Tags and DistributionStatisticConfig.

Why is this important?
Currently, Micrometer doesn't provide a straightforward way to reuse builders. This PR eliminates the need to fully describe all fields for each similar builder, thereby simplifying metric management.

Backwards Compatibility
This feature is partially backward-compatible:

• it doesn't affect existing methods and constructors for Meter's Builders and Tags
• but it changes DistributionStatisticConfig behavior and make it consistent with common Builder pattern
  (fix bug DistributionStatisticConfig object is mutable  #3489)

Test Coverage
CopyableTest class has simple test that verify new functionality, will extend it to cover all cases if you agree with design.

Usage Example
After this change, you can use new copy() method to create metric with dynamic tags

final Counter.Builder template = Counter.builder("counter");
template.copy().tags("tagA", "valueA").register(registry);
template.copy().tags("tagB", "valueB").register(registry);

[qweek]

Also suggest to make small breaking change and convert public DistributionStatisticConfig and DistributionStatisticConfig.Builder constructors to protected.
Now you can create new DistributionStatisticConfig(), but you can't change private fields.
You can create new DistributionStatisticConfig.Builder(), but also have builder() method with same functionality.

[jonatan-ivanov]

Let me collect similar/involved issues/PRs here:

• DistributionStatisticConfig object is mutable  #3489
• add DistributionStatisticConfig.toBuilder() #3949
• Make DistributionStatisticConfig extensible #3854
• Add Meter.Cache for dynamic meter registration #4092
• Add shortcuts to assign dynamic tags to Meters #4097

I think we should gather the use cases for this and what we can provide for this today, what changes might needed.

[qweek]

Some thoughts:

• DistributionStatisticConfig object is mutable  #3489
  Worth to fix. DistributionStatisticConfig will be immutable if we convert public constructor to protected.

• add DistributionStatisticConfig.toBuilder() #3949
  I'm not sure that I understand use case. Usually DistributionStatisticConfig is hidden in Builders, so maybe this case will be covered with reusable Builders.

• Make DistributionStatisticConfig extensible #3854
  As I understand, you had to create your own Builder to work with extendable DistributionStatisticConfig, but in this case in copy() method nested Builders will return parent classes. I will to try check if it works or not.

• Add Meter.Cache for dynamic meter registration #4092
  Cache is only 1 use case for factories, so it's better to make it more flexible.

• Add shortcuts to assign dynamic tags to Meters #4097
  I like this approach. It didn't create additional objects, but also cover only 1 use case and we need to add some custom logic above to make it work in other cases.

I prefer to split this problem into 2 parts:

• make more flexible builders (make it reusable, add additional methods to gauge, maybe add name() method, validate builders)
• collect use cases and find better solution for factories (delayed construction, caches, etc)

Right now, I know 2 use cases related to tags (dynamic tags and gauge with different objects/functions per dynamic tag)

[jonatan-ivanov]

@qweek Would #4097 solve your first use-case with dynamic tags and would using MultiGauge help in the second?

[github-actions]

If you would like us to look at this PR, please provide the requested information. If the information is not provided within the next 7 days this PR will be closed.

[github-actions]

Closing due to lack of requested feedback. If you would like us to look at this, please provide the requested information and we will re-open.