Remove prometheus legacy validation warning

[dmathieu]

I have been chatting with @bwplotka, who wouldn't recommend removing the support for the legacy scheme now.

Indeed, some system don't support the new scheme yet (such as cortex).
So removing this will entirely prevent those users form upgrading their SDK.

They are going to remove the deprecation from the legacy method on common, at least until the new scheme can be used in enough systems.

[XSAM]

We also need to remove this https://github.com/open-telemetry/opentelemetry-go/pull/6449/files#diff-fd6b3d75105c666a5fe2467725f6bff15ce0ebf4f6559dfaf484d6e26dba773dR30-R32

[dmathieu]

Good catch. I've changed the wording to say we'll be removing it in a future release, not the next one.

[bwplotka]

Thanks makes sense. Do you still need us to remove the "Deprecate" mark from related common code pieces?

We chatted a bit on KubeCon indeed and you mentioned that common pieces marked as "deprecate" is somehow blocking Otel Go SDK from using this functionality in a new stable version. I am trying to unpack that blocker, are you worried that deprecated entry AND the fact common is 0.x version increase risk of this functionality to be removed soon from common? I think it's a valid fear, which might be also "fixed" by committing to common v1 or vendoring core common pieces in client golang. Feel free to give us feedback on this issue!

cc @dmathieu

[dmathieu]

I think you can keep your deprecation.

We don't necessarily look at dependencies stability. If something is marked as deprecated, that's a sign for us that we don't want to use it. Especially if we're not stable on our end.
But as this PR shows, we're open to keeping deprecated things if that's warranted.

I guess the question now for us is what would be the signal indicating we can start looking into removing support for this?