fix(remix): Clone erroneous responses not to consume their body streams.

[onurtemizkan]

Fixes: #5423

Ref: #5405

We were extracting the bodies of 4xx/5xx responses to capture, but Remix also uses them, we should not consume their body streams, as they are only available once in response lifespans.

This PR updates extractData to work on a clone response.

[onurtemizkan]

Converted this to a draft, as it's not completely fixing #5425 (reporting an empty object for a simple 404 response with an empty body).

A question for the team:

Would it be reasonable to only capture 5xx responses instead? It seems users are not expecting a 4xx on their dashboard.

Or alternatively, maybe capturing only if there is a non-empty body inside the 4xx response?

[alexblack]

As a user I definitely wouldn't want 404 pages (not found) showing up in Sentry. However, I would want 400 errors (bad request) showing up in Sentry. However, if my loader has thrown a Response with status == 400 then I've likely handled an exception already...? (Same for status == 500)

[lobsterkatie]

Would it be reasonable to only capture 5xx responses instead? It seems users are not expecting a 4xx on their dashboard.

This would match what we do in other SDKs. Here's that check in the nextjs SDK, for example:

sentry-javascript/packages/nextjs/src/utils/_error.ts

Lines 28 to 32 in d2800c1

	// 404s (and other 400-y friends) can trigger `_error`, but we don't want to send them to Sentry
	const statusCode = (res && res.statusCode) || contextOrProps.statusCode;
	if (statusCode && statusCode < 500) {
	return Promise.resolve();
	}

We do tell folks in the docs how to catch 404s (on the front end). Maybe we should add a snippet for catching other 4xx errors, front and/or back end? Or maybe make it configurable on the backend? Regardless, IMHO that's a separate question from this one. Let's get this body fix in, make another PR to restrict it to 5xx, and take up the 4xx question separately.