fix: Sentry capturing compressed bodies when RequestDecompression middleware is enabled

[jamescrosswell]

Resolves #4312:

• Request.Body is not decompressed when Content-Encoding: gzip, even with ASP.NET Core’s UseRequestDecompression() #4312

Summary

Due to the SentryStartupFilter, Sentry's middleware is the first middleware in the chain, so was being called before the RequestDecompressionMiddleware. Because of this, the HttpContext.Request.Body that Sentry was storing on the Scope (and therefore events) was not being uncompressed as you would expect when enabling this middleware.

Solution

This PR alters the SentryStartupFilter so that it checks whether IRequestDecompressionProvider has been registered in the services collection (see RequestDecompressionServiceExtensions). If it is then the RequestDecompressionMiddleware is registered before Sentry's middleware.

So that we can capture any exceptions that may occur during decompression, we're using a custom RequestDecompressionMiddleware that we vendored in from https://github.com/dotnet/aspnetcore (all of the code we vendored in can be found in the src/Sentry.AspNetCore/RequestDecompression folder, with appropriate attribution).

Potential issues

• SDK users are very likely going to call app.UseRequestDecompression(); at some point, which will register the middleware a second time. This shouldn't cause any issues... the second instance of the middleware will return null from the call to _provider.GetDecompressionStream and then simply call the next middleware
  • Initially I thought we could prevent the middleware from being added a second time by using an IApplicationBuilder wrapper (as we do here for tracing). Unlike the tracing example, however, there are not properties/breadcrumbs left on the builder that can be used for this purpose... it could maybe be dome with some fairly complex reflection (for JIT compiled applications) but I'm not sure it's worth the effort.
• Uncompressed request bodies get stored in a SizeLimitedStream, which does not support Stream.Seek... we can't restore the stream position to 0 on this stream once we're done reading it then. We do EnableBuffering which hopefully mitigates any possible side effects of doing this.