Resolves: #6282

Implemented HTTPClient integration for @sentry/browser SDK.

Implementation Guide
Response Context Spec

This integration intercepts Fetch API and XHR requests to get the response (and request) information, and creates / captures events if there is a failed (according to the user's configuration) request.

Summary:

• This integration wraps XMLHttpRequest and fetch utilities, which can also be wrapped by other Sentry - non-Sentry utilities before or after it.
• Due to the limitations of both Fetch API and XHR, the cookie and header collection for both requests and responses is the best effort. Certain headers may be missing here in the integration-created event, even if they exist in the original request / response.
• The integration is opt-in and should be initialised as below to work:

Sentry.init({
  dsn: 'https://public@dsn.ingest.sentry.io/1337',
  integrations: [
    new Sentry.Integrations.HttpClient({
      // This array can contain tuples of `[begin, end]` (both inclusive), 
      // Single status codes, or a combinations of both.
      // default: [[500, 599]]
      failedRequestStatusCodes: [[500, 505], 507],

      // This array can contain Regexes or strings, or combinations of both.
      // default: [/.*/]
      failedRequestTargets: [/ab+c/, 'http://example.com/api/test'],
    }),
  ],
  // This is required for capturing headers and cookies. 
  // Without it, the `event.request` and `event.contexts.response` objects
  // will not include `headers` and `cookies`.  
  sendDefaultPii: true,
});

• The created events do not contain a stacktrace.
• body_size is calculated only if the Content-Length header is available in response headers.

fetch-specific Notes:

• Including body inside event.request object is not implemented here. It's not available at all for XHR requests, but here it's possible. Size limits and when to leave it out should be discussed, if we are including it.
• This implementation recreates a Request object from arguments of the fetch function. Not sure if there are any concerns about performance, but this is the most straightforward way I could find to replicate the original request object.
• Synthetically created request and native response objects are added to the event as hints, as described in the spec.

XHR-specific Notes:

• Request cookies are not accessible from XHR requests. We're intercepting setRequestHeader method, which is only used for user or library-defined headers. And setting Cookie with setRequestHeader is not allowed in browsers. due to security reasons.
• We also don't have a native request and response objects for XHR requests, so events created from failed XHR requests, do not contain hints.