libbeat/processors/util: make mac address rendering conform to ECS

[efd6]

What does this PR do?

This alters the syntax of hardware addresses to match the syntax that is specified in ECS.

Why is it important?

Currently it does not match the spec and this leaks out to integrations and modules in ways that are irritating to fix in ingest pipelines.

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

Author's Checklist

• [ ]

How to test this PR locally

Related issues

• Closes libbeat/processors/util: GetNetInfo formats hardware addresses incorrectly. #32264

Use cases

Screenshots

Logs

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2022-07-27T04:51:16.939+0000

• Duration: 90 min 9 sec

Test stats 🧪

Test	Results
Failed	0
Passed	22535
Skipped	1937
Total	24472

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

• /package : Generate the packages and run the E2E tests.

• /beats-tester : Run the installation tests with beats-tester.

• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[elasticmachine]

Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane)

[cmacknz]

My only hesitation with this is that it is a breaking change for anyone searching for MAC addresses. I suppose the argument for doing this is that anyone searching for MACs today would need to handle multiple possible formats already anyway since we don't standardize them.

[efd6]

I have the same concerns about the breaking change. The impetus for this is that the ECS specifies the format used in this change.

[mergify]

This pull request is now in conflicts. Could you fix it? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b 32264-libbeat upstream/32264-libbeat
git merge upstream/main
git push upstream 32264-libbeat

[mergify]

This pull request is now in conflicts. Could you fix it? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b 32264-libbeat upstream/32264-libbeat
git merge upstream/main
git push upstream 32264-libbeat

[andrewkroh]

I suppose the argument for doing this is that anyone searching for MACs today would need to handle multiple possible formats already anyway since we don't standardize them.

Agree. I'm viewing this as a bug in that we are inconsistent with the format specified by ECS for MACs. Plus with all of the Fleet integrations using the ECS specified format, we often end up with a mix of formats in the same event.

There are workarounds if someone needs the non-ECS format. A runtime field could be used to shadow the value and produce both formats or just the non-ECS format. Or a beat processor or ingest node processor could be used to revert to the old format.