Instrument LOG_EXCEPTION to observe a new Sentry disposition exception detail

[jtolio]

This will allow us to set NOSENTRY or SENTRY_DO or SENTRY_RT or similar on specific messages, designating how we handle these errors or what development team they go to, without adding strings to exception messages.

Also tie wdErrId fields more directly to the appropriate name.

[ask-bonk]

I'm Bonk, and I've done a quick review of your PR.

Adds Sentry disposition details to LOG_EXCEPTION output and tests their logging behavior.

1. Medium src/workerd/util/sentry.h:55 removes the compile-time-only context guard, allowing dynamic Sentry fingerprints. Posted one inline suggestion.

github run

[ask-bonk]

LGTM

github run

[jclee]

Seems OK to me, at least. I guess maybe worth noting that the change will probably affect the sentry fingerprints of existing exceptions, such that events will be recorded in new issues, but that's true of many code changes.

Might be worth adding a few samples of the new exception content to the internal sentry-handler library tests to verify that they submit the expected content.

[jtolio]

Seems OK to me, at least. I guess maybe worth noting that the change will probably affect the sentry fingerprints of existing exceptions, such that events will be recorded in new issues, but that's true of many code changes.

Might be worth adding a few samples of the new exception content to the internal sentry-handler library tests to verify that they submit the expected content.

Both issues fixed (fingerprint changes avoided and tests added) on this internal MR: https://gitlab.cfdata.org/cloudflare/ew/edgeworker/-/merge_requests/14737

(sorry to outside viewers for not getting to see)

[jtolio]

trivial rebases ^