Provide an option to customize meter name for HttpClient metrics

[beatfreaker]

Provides an option to customize meter name for metrics generated for requests that goes through HttpClient and HttpAsyncClient

Resolved gh-3706

[shakuzen]

Thank you for the pull request. It looks like CircleCI is having trouble loading the CI config. Could you try logging into CircleCI once? I believe that should fix the issue. You may need to update the branch to trigger another build if you can't do it from CircleCI's UI.

[shakuzen]

Thanks for the pull request. This mostly looks good, but I guess we haven't really figured out what to do about this comment. If you make a test where ObservationRegistry is configured on the instrumentation, I think you will see that your custom name does not get applied to the created Timer.

[beatfreaker]

@shakuzen added tests that results in showing that the custom metric name is not supported when ObservationRegistry is configured.
Also, the Javadoc added on Builder metricName(String name) stating that overridden metric name works only if ObservationRegistry is not configured should be fine right?

[shakuzen]

It's fine in so much as the behavior is consistent with the JavaDoc, but I don't think it's ideal behavior to be adding at this point where we would expect people in general to be migrating to using the ObservationRegistry in instrumentation and yet we're adding a new configuration method that does not do anything in that case. We could make it so DefaultApacheHttpClientObservationConvention took the configured name so that it would be used for the observation too unless a custom convention is configured. The unfortunate thing is that currently DefaultApacheHttpClientObservationConvention is designed as a singleton, so that's going to be broken if we make a constructor that takes a name. The no arg constructor can continue to use the existing default name, though. I think that might be a better path forward. @jonatan-ivanov what do you think?

[jonatan-ivanov]

I haven’t checked/tried this but if we want to make this configurable for that instrumentation, we might be able to provide a convention that extends the default and overrides the name to the user provided one but if we do that why isn’t the user the one then who provides it in the first place?

[shakuzen]

why isn’t the user the one then who provides it in the first place?

They certainly could provide a custom convention, but the main issue is that we will be adding a configuration for name that does nothing in case observation-based instrumentation is used. Users could simply pass a name for Timer-based instrumentation but have to provide a custom convention to do the same with Observation-based instrumentation.

I made this commit demonstrating what I was suggesting. It's certainly not without flaws. We didn't initially intend for default conventions to be used that way. I'm not sure which way is better. (I didn't make the equivalent changes to the hc5 package since it was to demonstrate my suggestion for review first)