With Go 1.23 released on 2024-08-13, we drop support for Go 1.21. This
means Go 1.22 is now our minimum supported Go release. Update our CI
files to reflect our current supported Go versions, and remove pre-Go
1.22 workarounds.

In addition to the CI bumps, this PR changes/fixes a few things related to the upgrade:

- Drops the old `rand` from the tracer, now that we can depend on `math/rand/v2`.
- Uses `slices` in the appsec package.
- The `TestWrapHandlerWithResourceNameNoRace` got a new data race. Specifically,
  by bumping our `go.mod` to 1.22, we get the new 1.22 ServeMux behavior internally.
  The 1.22 ServeMux modifies the Request, introducing a race with all the goroutines
  accessing/modifying the request concurrently. Fix it by giving each goroutine its own
  request. I verified that the test still catches the intended bug by reverting the fix from
  #2204 and verifying that the test fails.

Signed-off-by: Eliott Bouhana <[email protected]>

For tracking adoption of SSI for profiling, record whether the profiler
was added using Orchestrion and how the profiler was activated,
following the internal "Adding SSI information to profiles" RFC.

…utoinstrumentation (#2844)

Co-authored-by: Dario Castañé <[email protected]>

…Y_ENABLED` kill switch environment variable (#2861)

Co-authored-by: Juan Antonio Fernández de Alba <[email protected]>

)

Signed-off-by: Eliott Bouhana <[email protected]>

…ityEnabled and enable reporting Code Coverage percentage. (#2866)

Co-authored-by: Nick Ripley <[email protected]>

Signed-off-by: Eliott Bouhana <[email protected]>

#2869)

…#2883)

Signed-off-by: Eliott Bouhana <[email protected]>

)

The metrics profiler insisted on at least one second between collections
for two reasons:

- To avoid a division by zero because it was doing integer division to
  convert a time.Duration to seconds, which will truncate to 0, as a
  ratio in a subsequent computation
- In case "a system clock issue causes time to run backwards"

The profiler would report an error if less than one second elapsed
between collections. In practice, this resulted in misleading error logs
because it's entirely likely for profiling to be stopped less than a
second after the last profile collection.

The restriction was not really even needed. For one, we can just do
floating-point division rather than integer division to avoid the
truncation problem.

Also, Go has had monotonic time support by default since 2017, added in
Go 1.9, and time comparison operations including time.Time.Sub, work
with respect to monotonic time. We shouldn't have any issues with
negative periods. We can ensure the period is positive just as a
defensive measure, and fail if it's negative since this may indicate a
bug in the Go runtime if it's violating the monotonicity guarantees.

Fixes #2863

)

The fix in #2865 was intended to suppress spurious metrics profile
errors when the profiler is stopped. It did so by relaxing the
one-second duration constraint of the metrics profiler. However,
the Windows system timer resolution is about 15 milliseconds (see
https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/high-resolution-timers#controlling-timer-accuracy)
This caused the metrics profile tests from #2865 to fail because the
metrics profiler will likely be stopped in less than 15 milliseconds,
meaning we'll see 0 duration between profile collection and log an
error.

This commit actually suppresses the error by checking whether the
profiler was stopped (meaning interruptibleSleep was interrupted). If
so, and if the metrics profiler returned an error, we instead return a
sentinel error indicating that profiling was stopped. If we see that
error, we just drop the profile and don't log an error. We won't upload
the profile anyway. This way, we should only report an error from the
metrics profiler if there is _actually_ a problem with the timer.

Co-authored-by: Dario Castañé <[email protected]>

…pliance (#2849)

…NABLED to false (#2893)

Signed-off-by: Eliott Bouhana <[email protected]>

Signed-off-by: Eliott Bouhana <[email protected]>

…ry feature ended up with a failed test and then a successful test. (#2910)

…rt (#2887)

This test case is has been flaky for a long time. Per our policy, skip
it until we find a way to fix it.

For #2688

…runs (#2922)