feat: bump go version to 1.23

[kruskall]

Proposed commit message

go 1.24 has been released and 1.22 is EOL

bump to a supported version of go

(there might be an argument to bump to 1.24 to help with fips compliance but I'll open a followup PR for that)

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.

Disruptive User Impact

Author's Checklist

• [ ]

How to test this PR locally

Related issues

Use cases

Screenshots

Logs

[mergify]

This pull request does not have a backport label.
If this is a bug or security fix, could you label this PR @kruskall? 🙏.
For such, you'll need to label your PR with:

• The upcoming major version of the Elastic Stack
• The upcoming minor version of the Elastic Stack (if you're not pushing a breaking change)

To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-8./d is the label to automatically backport to the 8./d branch. /d is the digit
• backport-active-all is the label that automatically backports to all active branches.
• backport-active-8 is the label that automatically backports to all active minor branches for the 8 major.
• backport-active-9 is the label that automatically backports to all active minor branches for the 9 major.

[elasticmachine]

Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane)

[elasticmachine]

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

[v1v]

I've just updated this PR with the relevant changes to use the golang-crossbuild in ARM64 for ARM64. It requires further changes in:

• .buildkite/x-pack/pipeline.xpack.dockerlogbeat.yml - unitTest step uses golang-corssbuild, so it requires the qem thing.
• .buildkite/metricbeat/pipeline.yml - crosscompiles step uses golang-crossbuild, so it requires the qemu thing

[dliappis]

LGTM, thank you everyone for pushing this through!

There were a few CI metricbeat module related CI errors but to me they looked unrelated to this PR, I clicked retry anyway to see if they are transient.

[dliappis]

Thanks for pushing through this @v1v and @kruskall LGTM!

I noticed an earlier failure for x-pack/osquerybeat which seems to have passed with the latest CI run which made me investigate a bit more; turns out that contrary to every other beat, we don't have a dedicated linux/arm64 packaging step for x-pack/osquerybeat either in DRA on in the PR packaging steps.

Going forwards we probably want to file a ticket and implement this too, so that building arm64 for x-pack/osquerybeat is done without qemu emulation but inside a dedicated worker too (as done for every other beat).

[andrewkroh]

Approving changes to packetbeat/* and auditbeat/*

[v1v]

I noticed an earlier failure for x-pack/osquerybeat which seems to have passed with the latest CI run which made me investigate a bit more; turns out that contrary to every other beat, we don't have a dedicated linux/arm64 packaging step for x-pack/osquerybeat either in DRA on in the PR packaging steps.

See #43019 is now the implementation.

Going forwards we probably want to file a ticket and implement this too, so that building arm64 for x-pack/osquerybeat is done without qemu emulation but inside a dedicated worker too (as done for every other beat).

I might say something a bit different and in my view, we might to revisit what's implemented and create a table or something that can allow us to know what stages run and when.

Back in the day, I used https://github.com/elastic/beats/blob/7.17/.ci/scripts/generate_build_table.py to create that table by reading all the Jenkinsfile.yml. I don't know whether that's something we can easily accomplish, but maybe something we can think about.