Track unmapped services in Usage Ping

What does this MR do?

Refs #229457 (closed) which contains our latest findings from collecting Omnibus topology data from on-premise installations.

For Usage Ping, we currently track which GitLab services customers run on which Omnibus node. For privacy reasons, we currently skip service data for services that we think we do not know or aren't ours. However, that makes it impossible to understand how complete our picture of customer topology is. Moreover, we saw a few cases where we think our node mapping logic failed us, because related service data may have been mapped onto two different nodes when they should have been mapped to the same.

This MR addresses these problems by including a failure element whenever we fail to map a job name to a GitLab service as defined in the allow-list. The failure will carry the service name. This will help us understand whether it was just a mapping entry we forgot to add or whether customers run Prometheus job config for services we did not anticipate.

Does this MR meet the acceptance criteria?

Conformity

• [-] Changelog entry
• [-] Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• [-] Database guides
• [-] Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• [-] Tested in all supported browsers
• [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done