Remove deprecated code in 3.0

Context

There are a number of deprecated APIs / compatibility shims in the repo that are already annotated with comments like:

• @Deprecated // to be removed in 3.0
• @Deprecated // will be removed in 3.0.0
• Javadoc text such as Will be removed in 3.0

Issue #15806 is one example of this pattern (IgnoredTypesConfigurer#configure(IgnoredTypesBuilder, ConfigProperties)).

There is also a second, related marker for APIs that are renamed rather than removed in 3.0:

• // will be renamed in 3.0 to <name>()

These are transitional names taken by a new API that had to coexist with a legacy one it could not be distinguished from by overloading. Once the legacy method is deleted, the transitional name collapses back to the plain name.

Goal

Before / during the 3.0 work, remove the APIs and compatibility code that are already explicitly marked for removal in 3.0, and collapse the transitional names back to their plain form.

Suggested approach

Use the existing comments as the source of truth and audit all matches. The two passes are ordered: a rename is only possible once the removal pass has freed up the target name.

# pass 1 - removals
git grep -n "will be removed in 3.0.0\|to be removed in 3.0\|Will be removed in 3.0.0\|Will be removed in 3.0"

# pass 2 - renames (only after pass 1 frees up the target names)
git grep -n "will be renamed in 3.0"

Then remove the marked APIs / shims and any now-unneeded compatibility code, tests, and docs, and apply the renames.

Notes

• Some matches are public API deprecations.

• Some matches are internal compatibility paths or temporary annotations/comments.

• The audit should confirm each remaining match is still intended for 3.0 removal.

• The messaging v1.43 stack (#19347-#19357) introduces two renames:

  transitional name (2.x)	3.0 name
  MessagingProducerMetrics.getForOperationType	get
  MessagingConsumerMetrics.getForOperationType	get

  Both are blocked behind pass 1, which removes the deprecated get() overloads currently holding
  those names. MessagingProducerMetrics.getForOperationTypeWithOldMetrics and
  MessagingConsumerMetrics.getForOperationTypeWithOldMetrics are marked // to be removed in 3.0
  and so are handled by pass 1 as well, not by the rename pass.

  The extractors need no rename. MessagingAttributesExtractor.create / builder,
  MessagingSpanNameExtractor.create / builder and MessagingSpanKindExtractor.create are each
  overloaded on MessagingOperationType versus the deprecated MessageOperation, so deleting the
  latter in pass 1 is enough. An earlier revision of the stack gave MessagingAttributesExtractor
  distinct *ForOperationType names to avoid a null-literal ambiguity between its two overloads;
  that was replaced by plain overloads, so only the two metrics accessors above still carry a
  // will be renamed in 3.0 to get() marker.