feat(core): Ensure replay envelopes are sent in order when offline

[timfish]

Closes #11207

This PR modifies makeOfflineTransport to allow replay envelopes to be queued when offline and to ensure they are always send in order.

To do this we:

• Modify the store interface so it has push, unshift and shift methods (BREAKING)
• Always queue replay envelopes in the store so there is never more than one in-flight
• Always unshift failed envelopes so they're always sent in the same order from the queue

These changes do not ensure ALL envelopes are sent in order as the only way to do that would be queuing all envelopes and waiting on their completion before moving on to the next.

The major downside to queuing replay envelopes is that from replays perspective, they never fail to send and the retry logic is redundant.

[Lms24]

Can we add a test for replays with the offline transport in our browser integration tests? I think there's already one for the offline transport with errors but it might make sense to cover replay events as well now. If it turns out to be flaky or too much of a hassle, no worries, we can leave it as-is.

[timfish]

It looks like we can't round-trip serialise/parse envelopes in the browser tests because of this:
vitest-dev/vitest#4043 (comment)

This means that a Uint8Array created by jsdom is not an instanceof Uint8Array in node which means at the serialisation step, the buffer is converted to JSON.

It might be easier to add this as an integration test instead!

[Lms24]

It might be easier to add this as an integration test instead!

yup, sounds good!

[timfish]

Ah scrap that, I managed to get it working.

He says confidently and then it fails in CI

[timfish]

The tests are finally passing!

[Lms24]

Thanks Tim!

[timfish]

This is failing in CI due to some unrelated playwright test:
https://github.com/getsentry/sentry-javascript/actions/runs/8612639079/job/23602437605?pr=11413#step:10:128

Looking at the captures trace, it's failing due to CORS issues...