[Apollo] Tighten namespace around metrics

[abernix]

What does this PR do?

This aims to tighten the namespace which are part of our DataDog Marketplace integration to just the set of metrics which are emitted (from the SaaS side of our Apollo product) which pertain to the Marketplace integration rather than those that are emitted by our (different) on-prem product, Apollo Router which emits its metrics into an apollo.router.-prefixed namespace. This apollo.router. namespace should not prevent users from losing control over the management of tags in their UI.

What this PR does not do is remove apollo.engine. from the list of checks, though it is tempting to do that at the same time. What is not clear is what the implications of that are as this is a deprecated namespace.

Relates to #2529

Motivation

We're opening this only because we're finding customers who are using our on-prem metrics are being forbidden by the DataDog UI to adjust those metrics in the way they would manage tags on other metrics.

Review checklist

• PR has a meaningful title or PR has the no-changelog label attached
• Feature or bugfix has tests
• Git history is clean
• If PR impacts documentation, docs team has been notified or an issue has been opened on the documentation repo
• If this PR includes a log pipeline, please add a description describing the remappers and processors.

Additional Notes

Happy to help satisfy the Review checklist, but primarily looking for feedback if this will accomplish what we want, or if there is another way this should be done.

[abernix]

I'm curious if the manifest supports having an array here? It would seem safer conceptually to me — to preserve behavior of our legacy apollo.engine. namespace — to have this be ["apollo.operations.", "apollo.engine."]and _not_ addapollo.router.` to that list (which is the primary set we're trying to unblock tag-editing access for).

[abernix]

I'll switch this to a draft, but we could really use guidance on what the most practical path forward would be to "preserve whatever is already working on apollo.engine. for folks who won't migrate off that for a while, but also unblocks the ability to edit apollo.router. tag metrics."

We're of course happy if apollo.operations.* (plus apollo.engine.*, historically) continues to have that tag-editing limitation in the UI, but just don't know how to craft that into the manifest's desired format.