NMS-19752: Use compact wire marshalling for IPC and embedded payloads

[JSimo]

Cleaned up the previous basic POC change on our end with not pretty printing the XML sent on Kafka. This change reduces CPU usage in our opennms instance by 1-2%. And more than halves the CPU usage of the marshalling. So not as fun as the enlinkd changes which reduced it by an entire cpu core. Currently running this in our full scale (50k nodes, 1mil+ interfaces) test instance successfully.

^Usage before fix, noticeable part.

No rush to review this, as it is an change, it though to be clear non-breaking and entirely compatible change for any minion listener. It is an part of an push to go through our forked 35.x branch see what POC changes we have that should be cleaned up and upstreamed.

---

Add MarshallerProfile (WIRE/CONFIG) with unified marshaller setup and per-thread caching. RPC, sink, and tracing use the wire profile; config file embeds keep CONFIG marshal-time XSD validation.

Split poller embedded marshalling by context: PollerWireClassObjectAdapter for RPC attributes (compact, no marshal XSD) and PollerClassObjectAdapter for poller-configuration.xml parameters. Marshal embedded payloads via DOMResult instead of marshal-to-string plus DocumentBuilder.parse.

Add unit tests for wire/config profiles, poller adapter behavior, and RPC wire round-trips.

All Contributors

• Have you read our Contribution Guidelines?
• Have you (electronically) signed the OpenNMS Contributor Agreement?

Contribution Checklist

• Please make an issue in the OpenNMS issue tracker if there isn't one already.
  Once there is an issue, please:
  1. update the title of this PR to be in the format: ${JIRA-ISSUE-NUMBER}: subject of pull request
  2. update the Jira link at the bottom of this comment to refer to the real issue number
  3. prefix your commit messages with the issue number, if possible
  4. once you've created this PR, please link to it in a comment in the Jira issue
     Don't worry if this sounds like a lot, we can help you get things set up properly.
• If this code is likely to affect the UI, did you name your branch with -smoke in it to trigger smoke tests?
• If this is a new or updated feature, is there documentation for the new behavior?
• If this is new code, are there unit and/or integration tests?
• If this PR targets a foundation-* branch, does it try to avoid changing files in $OPENNMS_HOME/etc/?

What's Next?

A PR should be assigned at least 2 reviewers. If you know that someone would be a good person to review your code, feel free to add them.

If you need help making additions or changes to the documentation related to your changes, please let us know.

In any case, if anything is unclear or you want help getting your PR ready for merge, please don't hesitate to say something in the comments here,
or in the #opennms-development chat channel.

Once reviewer(s) accept the PR and the branch passes continuous integration, the PR is eligible for merge.

At that time, if you have commit access (are an OpenNMS Group employee or a member of the OGP) you are welcome to merge the PR when you're ready.
Otherwise, a reviewer can merge it for you.

Thanks for taking time to contribute!

External References

• Jira (Issue Tracker): https://opennms.atlassian.net/browse/NMS-19752