{,x-pack/}auditbeat: remove unused fields and params and mark platform-specific code

[efd6]

What does this PR do?

This removes the majority of unused identified by running:

staticcheck -checks 'U*' ./{,x-pack/}auditbeat/...

Care has been taken to not remove platform-specific code and mage-required code.

This is the auditbeat part of #30483.

Why is it important?

Deadcode reduces code base maintainability.

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

• Should be checked with the view to save deletions from the gallows. I will add lint ignore directives for chunks that are to be retained and revert those chunks.

How to test this PR locally

Related issues

• Relates {,x-pack/}filebeat: clean up dead code #30483.

Use cases

Screenshots

Logs

[elasticmachine]

Pinging @elastic/security-external-integrations (Team:Security-External Integrations)

[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-02-21T04:14:30.230+0000

• Duration: 77 min 31 sec

Test stats 🧪

Test	Results
Failed	0
Passed	862
Skipped	162
Total	1024

💚 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!)

[andrewkroh]

IIUC this is a comment for staticcheck. If we decide to standardize on golangci-lint then will this need to change to the //nolint:staticcheck // <comment> format?

[efd6]

Yes, this needs discussion. It would be good if golangci-lint honoured its dependencies' linter directives (this is golangci/golangci-lint#1658). In the past the coverage of lint classes by staticcheck was quite a lot less than for the metalinters, this is less true now (vim-go defaults now to staticcheck now and gopls integrates it (currently experimentally)), so when incremental linting is possible with staticcheck I think that is would be the better option (also for the reason of the default-on .so loading that golangci-lint does). These were in my thinking when I wrote this, with the view that it could be changed down the track if an alternative decision were made.