Move linting to a Github action for better integration

[rdner]

What does this PR do?

Now the linting issues will be displayed in the PR diff on Github and
one can see the issues inline during the review.

Why is it important?

After getting some feedback related to #30896
and some testing of the Github action in elastic/elastic-agent-libs#30 the solution how to make this setup reliable was found and now we can switch to the Github action.

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.

Logs

[elasticmachine]

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

[mergify]

This pull request does not have a backport label. Could you fix it @rdner? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-v./d./d./d is the label to automatically backport to the 7./d branch. /d is the digit

NOTE: backport-skip has been added to this pull request.

[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-24T08:37:02.195+0000

• Duration: 67 min 30 sec

Test stats 🧪

Test	Results
Failed	0
Passed	22523
Skipped	1940
Total	24463

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

[v1v]

I'm not sure if this is needed, we have not been filled any details in the changelog related to the CI/CD, if it helps

[rdner]

Well, I put it there the last time I changed the CI. Since it's just for developers, I think it would not hurt.

[v1v]

@rdner, is there any specific platform dependency while running golang-lint on windows and darwin? If so, I see down below the runs-on: ubuntu-latest, is that expected while running on windows/darwin too? I wonder if this matrix could be reduced to one OS (linux) if the outcome is the same for the other two platforms

[rdner]

@v1v We have to run the linter against every platform (GOOS) we have any Go code for, otherwise any platform-specific code is not inspected and issues are not reported.

It does not matter on which OS it's running physically (ubuntu-latest), it's just an environment variable that tells the Go compiler which files to compile.

For Darwin we have these:

./metricbeat/internal/metrics/memory/memory_darwin.go
./metricbeat/internal/metrics/cpu/metrics_darwin.go
./auditbeat/module/file_integrity/fileorigin_darwin.go
./libbeat/statestore/backend/memlog/util_darwin.go
./libbeat/metric/system/process/process_darwin.go
./x-pack/osquerybeat/ext/osquery-extension/main_darwin.go

For Windows we have these:

./metricbeat/module/windows/service/zservice_windows.go
./metricbeat/module/windows/service/defs_service_windows.go
./metricbeat/internal/metrics/memory/memory_windows.go
./metricbeat/internal/metrics/cpu/metrics_windows.go
./metricbeat/internal/sysinit/system_windows.go
./metricbeat/helper/privileges_windows.go
./metricbeat/helper/dialer/dialer_windows.go
./metricbeat/helper/windows/pdh/zpdh_windows.go
./metricbeat/helper/windows/pdh/pdh_windows.go
./metricbeat/helper/windows/pdh/pdh_query_windows.go
./metricbeat/helper/windows/pdh/defs_pdh_windows.go
./filebeat/input/file/identifier_test_windows.go
./filebeat/input/file/identifier_inode_deviceid_windows.go
./filebeat/input/default-inputs/inputs_windows.go
./filebeat/input/filestream/fswatch_test_non_windows.go
./filebeat/input/filestream/identifier_inode_deviceid_windows.go
./filebeat/input/filestream/filestream_test_non_windows.go
./filebeat/input/filestream/identifier_test_non_windows.go
./auditbeat/module/file_integrity/fileinfo_windows.go
./auditbeat/module/file_integrity/security_windows.go
./auditbeat/module/file_integrity/zsecurity_windows.go
./winlogbeat/checkpoint/file_windows.go
./winlogbeat/sys/winevent/sid_windows.go
./winlogbeat/sys/wineventlog/syscall_windows.go
./winlogbeat/sys/wineventlog/zsyscall_windows.go
./winlogbeat/sys/wineventlog/wineventlog_windows.go
./winlogbeat/eventlog/errors_windows.go
./packetbeat/npcap/npcap_windows.go
./packetbeat/procs/syscall_windows.go
./packetbeat/procs/zsyscall_windows.go
./packetbeat/procs/procs_windows.go
./libbeat/logp/eventlog_windows.go
./libbeat/statestore/backend/memlog/util_windows.go
./libbeat/processors/decode_xml_wineventlog/decoder_windows.go
./libbeat/common/file/helper_windows.go
./libbeat/common/file/fileinfo_windows.go
./libbeat/common/file/stderr_windows.go
./libbeat/common/file/file_windows.go
./libbeat/api/npipe/listener_windows.go
./libbeat/api/make_listener_windows.go
./libbeat/service/service_windows.go
./libbeat/metric/system/numcpu/cpu_windows.go
./libbeat/metric/system/diskio/diskstat_windows.go
./libbeat/metric/system/process/process_windows.go
./x-pack/osquerybeat/ext/osquery-extension/main_windows.go
./x-pack/osquerybeat/internal/install/install_windows.go
./x-pack/osquerybeat/internal/osqd/osqueryd_windows.go
./x-pack/auditbeat/module/system/package/package_windows.go
./x-pack/winlogbeat/module/testing_windows.go
./x-pack/packetbeat/npcap/npcap_windows.go
./x-pack/libbeat/common/proc/job_windows.go

[v1v]

Thanks for the clarification! It makes totally sense now :)