Feat (312): stabilize client side otel export

[myieye]

An attempt at #312

If an export fails it gets retried with XHR. We can try a more ambitious export size now, because it doesn't matter as much if it fails. Also, a higher number helps us pump things through faster, so it's less likely that we'll lose something on page unload. I initially thought we'd lose insight into export failures this way, but I think that's not really the case, because either:

1. We'll just retry with XHR and it will probably be ok, so the failure doesn't matter
2. It's too late to retry and so we likely wouldn't see the failure anyway

There's of course the 3rd scenario: when the error would have been reported before: (1) we start the retry instead, (2) the page gets unloaded and (3) the XHR/retry gets canceled and we can't report the failure. But that shouldn't happen too often.

Of course, we're not really trying to instrument our instrumentation export failures, but it is nice to know if it's not working well.

[github-actions]

UI unit Tests

1 tests  ±0   1 ✔️ ±0   0s ⏱️ ±0s
1 suites ±0   0 💤 ±0 
1 files   ±0   0 ❌ ±0 

Results for commit 4c16f6c. ± Comparison against base commit 7a7d781.

♻️ This comment has been updated with latest results.