feat(change-stream): Account for upload sessions and markers

[lcian]

Reports resumable upload-related changes to the ChangeStream.

• Markers are reported by the HighVolumeBackend with standard WRITE/DELETE changes and their hardcoded 5 day TTLs.
• In-progress LT upload sessions are reported with new WRITE_SESSION and DELETE_SESSION op_types, with the length requested by the user plus backend metadata bytes at upload creation and hardcoded 7 days TTL.

We cannot reuse WRITE/DELETE for in-progress LT uploads, as GCS actually doesn't bill storage costs for them, so the COGS consumers would incorrectly report extra costs.
We therefore need to update the Kafka schemas to receive this new op_type (getsentry/sentry-kafka-schemas#504) as well as the COGS query (https://github.com/getsentry/etl/pull/2936).
The above needs to be done before this change is deployed.

@matt-codecov please let me know what you think about this approach, alternatively we can go with one of these alternatives:

• Reuse WRITE/DELETE for in-progress sessions, and avoid sending them through the ChangeStream only in GCS. We would only do that because we know this is being used for COGS, even though ChangeStream is a general interface, so that doesn't sound right.
• In the ChangeStream, if the change is coming from GCS and it's a session, ignore it. This also doesn't sound right, because the COGS ChangeStream by design doesn't know or care which backend the change came from.

Closes FS-563

[linear-code]

FS-563

[cursor]

Stale Bugbot comment from a previous run.

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 250bed0. Configure here.}

[matt-codecov]

We cannot reuse WRITE/DELETE for in-progress LT uploads, as GCS actually doesn't bill storage costs for them, so the COGS consumers would incorrectly report extra costs.

actually, isn't this solved by emitting a write on completion rather than session creation in the LT backend? and if there is a backend that does bill for pre-finalized objects, then they could emit writes earlier?

there is still the problem of enabling GC to clean up abandoned sessions. but i think that problem might go away with changes we're considering:

• making all deployments tiered
• the addition of begin_write() from ref(change-stream): Make ChangeStream async, fallible, and cover before/after commit #677

with those changes, backends don't have to keep pre-finalized objects in separate namespaces anymore because there won't be a tombstone pointing at the LT revision until it's finalized. so when a session is opened, begin_write() will create a sizeless record of it in the GC inventory with the short expiry, and when it's finalized commit_write() will update with the size and the finalized expiry