"Applying" potential Copilot code review rules

[trask]

Hopefully this is reflective of the changes copilot code review will suggest after #2170.

Please comment either here or there if you have suggestions about the style-guide.md that was used to generate this PR.

This PR was generated by running this prompt module-by-module:

Make minimal changes to update {module} module to follow all of the recommendations in docs/style-guide.md. Ignore the @Nullable annotation usage section of the style guide.

I made very minor manual fixes to Copilot's work after the fact, including reverting adding final to public classes in the stable aws-xray module.

(I skipped the consistent-sampling module for now, will apply to that later)

[KarstenSchnitter]

I reviewed the changes to the cloudfoundry-resources subproject. They look fine, I approve.

[SylvainJuge]

LGTM for the following modules:

• inferred-spans
• jmx-metrics
• jmx-scraper
• span-stacktrace

[breedx-splk]

Seems harmless but I don't immediately see why it's required.

[trask]

yeah, removed

[trask]

I found out this is required, because javac -Werror on the test files throws an error if it can't find the annotations used on the classes that the tests reference 🤯

Which I assume affects downstream consumer of our libraries also as long as we make autoservice a compileOnly dependency.

so I reverted all the autoservice changes in this PR so we can discuss it separately

[breedx-splk]

oh wild! thanks for seeing that through...did not expect that. :)

[breedx-splk]

Hmmm, this is fine I guess, but this one seems less idiomatic to me.

[breedx-splk]

So @trask and I talked a little bit about this out of band. I think it's good, but we agreed that the classes in "internal" packages (and also package-private) should retain their final designations (which this PR attempts to remove).

The final is good because it also discourages other developers, even within the project itself, from introducing inheritance, and it maintains the status quo.

Otherwise, looks pretty good.

[zeitlinger]

looks like improving @Nullable (or adding NullAway) is still too hard - right?

[trask]

looks like improving @Nullable (or adding NullAway) is still too hard - right?

I'll try that in a follow-up (didn't try it yet)

[breedx-splk]

Was a11d406 just done with an abundance of caution because users might have done inheritance? I wish we could keep that, but won't hold this PR up with it.

[breedx-splk]

I think it's in pretty good shape now.

[trask]

Was a11d406 just done with an abundance of caution because users might have done inheritance? I wish we could keep that, but won't hold this PR up with it.

yeah, I plan to send that in a follow-up, realized I should draw a bit more attention to that change since it's a breaking change (to alpha modules)