Explore performance improvements in golang generation pipeline

[nogates]

What does this PR do?

This PR focuses on improving CI pipeline performance and maintainability for the datadog-api-client-go repository. The two main pain points targeted were the long test job runtime — caused by bundling static analysis directly inside every test matrix runner — and the monolithic example build that was running all 1,490 examples sequentially in a single job. The changes decouple these concerns both organizationally and in terms of execution time.

Staticcheck was previously installed from source (go install honnef.co/go/tools/cmd/staticcheck@latest) and run inline inside run-tests.sh, meaning every one of the four test matrix jobs (Go 1.22 × 1.23 × two build tag variants) had to pay the cost of downloading, compiling, and running it before tests could even start. This has been replaced with a dedicated staticcheck job in the reusable Go test workflow using the official dominikh/staticcheck-action@v1. The action ships a pre-built binary with its own caching layer, and —crucially — it now runs in parallel with the test jobs rather than being on their critical path, removing it entirely from the test job's wall-clock time.

Example builds went from a single job compiling all 1,490 example packages in sequence (~7 minutes on GitHub's 2-core runners) to a two-stage matrix workflow. A lightweight prepare job counts the examples and emits a dynamic matrix JSON (currently [1,2,3,4] for 400 examples per group). Four build jobs then run in parallel, each checking out the repo and building its own slice. Based on the observed 7-minute baseline for 1,490 examples, each group of ~375–400 examples is expected to take around 1.9 minutes of build time, bringing the total wall-clock time — including checkout and Go setup — to roughly 2.5–3 minutes, down from 7. The group size is controlled by the EXAMPLES_PER_GROUP variable in both scripts, so it can be tuned as the example count grows over time.

Overall, these changes reduce the two longest-running CI steps by roughly 55–60% in wall-clock time, without sacrificing coverage or correctness. The test job is now leaner and focused purely on running tests; static analysis and example validation each run in their own dedicated, parallelised jobs. The approach is also future-proof: as new examples are added, the matrix automatically gains more groups to keep each job within the target budget.

Additional Notes

Review checklist

Please check relevant items below:

• This PR includes all newly recorded cassettes for any modified tests.

• This PR does not rely on API client schema changes.

  • The CI should be fully passing.

• Or, this PR relies on API schema changes and this is a Draft PR to include tests for that new functionality.

  • Note: CI shouldn't be run on this Draft PR, as its expected to fail without the corresponding schema changes.