Tidy up java code in o.a.s.metrics package

[epugh]

Description

Reviewing code in the org.apache.solr.metrics package for potential improvements.

Solution

Mostly driven by what IntelliJ is suggesting are weaknesses. Specifically, there were quite a few unused methods and classes in the Metrics package. I debated removing them, so I kept them in a single commit to make it easy to undo it. I odn't know if having htose methods etc was for OTHER consumers of Solr? @mlbiscoc I'd love your opinon on this.

Tests

I had to tweak them just a bit after editing. Otherwise just rerunning them.

[mlbiscoc]

The rest of these changes I am good with. Was just some mess I accidentally may have left behind. Thanks for tidying this up!

[mlbiscoc]

So for these instruments, I purposely created them as tools if someone wanted to capture metrics with these doubles in the future even though I didn't use them myself on the migration. All of our metrics back then I don't think did things with doubles and it was all longs but with OTEL we are not constrained to that anymore.

I personally prefer to keep them for future developers so they know that these tools do exist. Or maybe an LLM sees these exist and decides this is the best instrument instead of the ones we used.

[dsmiley]

agreed.

[epugh]

thanks for chiming in.. I worry about YAGNI, but also get the reasons for keeping it. I'll back out those changes, and then look to merge... Anything else that looks iffy?