{,x-pack/}{auditbeat,packetbeat,winlogbeat,filebeat/input/httpjson}: fix lint and silence linters

[efd6]

What does this PR do?

Fixes lint or suppresses linter complaints depending on issue.

Why is it important?

This will remove the need to include irrelevant diff noise in future PRs forced by the linter.

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

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-03-28T23:01:55.843+0000

• Duration: 74 min 40 sec

Test stats 🧪

Test	Results
Failed	0
Passed	4552
Skipped	264
Total	4816

💚 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/security-external-integrations (Team:Security-External Integrations)

[andrewkroh]

While this is true, maybe we should go ahead and change these two over to to errors.Is() anyways?

[efd6]

I'm not convinced. Errors is requires at least one call to reflectlite in all cases in order to check whether the error value is comparable. I think that if we know that the error is always unwrapped (for example it comes from a stdlib function that always did, like in the case of all uses of io.EOF) then it would be better to use the old convention; also for readability (though this is harmed by nolint spam).

I am happy to go over and change them all if you feel strongly about it though.

[andrewkroh]

I don't feel strongly about. I just haven't accepted that we'll have so many of these//nolint statements 😄.

[efd6]

I just haven't accepted that we'll have so many of these//nolint statements 😄.

Indeed. This is a consequence of the approach that golangci-lint takes to linting; it tries to cover too much and it does so with sometimes less than careful linters.

The nolint directives will help with the follow up to the linting process though; if we see many unuseful lint complaints from a particular linter we can argue to have it removed.