Polish MicrometerHttpClientInterceptor changes

[izeye]

This PR polishes the MicrometerHttpClientInterceptor changes made in #1886.

[izeye]

The build has failed due to the dependency locking as follows:

* What went wrong:
Execution failed for task ':micrometer-samples-boot2:compileJava'.
> Could not resolve all files for configuration ':micrometer-samples-boot2:compileClasspath'.
   > Resolved 'org.latencyutils:LatencyUtils:2.0.3' which is not part of the dependency lock state
   > Resolved 'io.micrometer:micrometer-core:1.3.0' which is not part of the dependency lock state

I couldn't reproduce it locally.

[shakuzen]

I made this pull request partially for the purpose of seeing if the failure would happen there. It didn't. So I'm wondering if it has something to do with the build running on your CircleCI instance rather than the Micrometer one?

[izeye]

@shakuzen Thanks for the review and the build check! Your assumption seems right although I'm not sure why and how it happened as it used to work before and there's nothing changed or special there.

[shakuzen]

I'm not sure why and how it happened

I'm not sure either. If I had to guess, it might have something to do with how we're caching things with CircleCI, which has always been in the back of my mind as something to iterate on and improve, but it hasn't had more urgency than other things so far. Namely, the cache key is based only on a checksum of the root build.gradle, but the build dependencies (and anything else in ~/.gradle) could change due to changes in a number of other files. I've always wished this was taken care of more out of the box rather than us having to figure out the right cache key to use. This is perhaps something that if I enable Gradle Enterprise features we could have a better experience. This is all assuming that this has anything to do with the build failure mentioned here. My theory is that something was cached with a previous build having the same root build.gradle file that doesn't play nicely with changes to other files, but is still loaded due to the cache key. Just a guess, though.

[izeye]

@shakuzen Thanks for the info!

I invalidated the cache by adding a newline at the end of the build.gradle and confirmed a cache miss as follows:

No cache is found for key: gradle-dependencies-09FfXX5vix3yF+XMTk87ckzATHWfdbQlECqdU2t+rsg=

But I still see the same failures.

See https://circleci.com/gh/izeye/micrometer/678