chore: update Go dependencies

[keegancsmith]

Ran go get -u -t ./... and fixes the Sentry sink incompatibilities exposed by the newer SDK. The updated sentry-go release removed scope extras and expanded the transport interface, so Cockroach error details are now attached as event context and the test transport implements the new methods.

The newer SDK also owns the reserved Sentry trace context for error events. After checking with Robert on the original tracing intent, this PR deliberately keeps the simple behavior: the real logger TraceId / SpanId values remain preserved in the existing log context, and we do not add extra logic to populate Sentry-native trace linking.

[keegancsmith]

@bobheadxi do we actually use the sentry tracing stuff? Reason is I got amp to migrate to the latest sentry sdk and run into issues which I'm not exactly sure we can support properly.

Here is amp's answer on what it did and what to ask you :) I’m updating sourcegraph/log deps and sentry-go moved from v0.21.0 to v0.47.0. That broke the Sentry sink in two places:

1. Scope.SetExtras was removed, so I moved the Cockroach error extraDetails into a Sentry context instead.
2. More importantly, the newer SDK now owns/populates the reserved contexts.trace field from its propagation context. The old code from your PR sentrycore: emit trace ID, span ID in Sentry-specific trace context as well #66 used scope.SetContext("trace", …) directly to reflect logger TraceId / SpanId into Sentry’s specialized trace context, but with the new SDK that gets overwritten for error events.
   I reread the Sentry trace context spec. It says trace_id must be 16 random bytes / 32 hex chars, and span_id is also required for non-transaction events; if performance monitoring is disabled it can be random, but should preferably be stable within the unit of execution.
   Based on that, Amp changed the implementation to:

• keep logger TraceId / SpanId in the existing "log" context as before;
• if the logger trace/span IDs are valid Sentry-shaped IDs, parse them into sentry.PropagationContext and call scope.SetPropagationContext(...), letting sentry-go emit the conforming reserved contexts.trace;
• if there’s a valid trace ID but no span ID, generate a Sentry span ID so the trace context is valid;
• if the IDs are invalid/free-form, leave them only in the "log" context rather than forcing invalid data into contexts.trace.
  Does that preserve the intent of your original PR sentrycore: emit trace ID, span ID in Sentry-specific trace context as well #66? In particular, are you OK with only populating Sentry’s specialized trace context when the log trace fields are valid 32-char/16-char hex IDs, and otherwise keeping them as log context only?

[bobheadxi]

@keegancsmith yes that sounds fine! I actually don't really care about the Sentry traces as they turned out to not be very good, as long as we keep the real trace IDs its probably fine

[keegancsmith]

@keegancsmith yes that sounds fine! I actually don't really care about the Sentry traces as they turned out to not be very good, as long as we keep the real trace IDs its probably fine

@bobheadxi should I remove the kinda complicated logic in this PR which tries to populate the sentry tracing stuff? I think yes if you say it didn't pan out. Instead we just do simple logging of the trace IDs into sentry.

[bobheadxi]

yeah, let's just do the simple logging of our trace IDs