Configure Sentry tracing middleware automatically

[jamescrosswell]

Addresses Sentry tracing middleware should be added automatically #2202.

With this PR, it's almost never necessary for SDK users to call UseSentryTracing anymore, which will hopefully make it way easier for SDK users to get started with Sentry Tracing.

Approach

We've used a much simpler variant of Andrew Lock's solution:

• We register SentryTracingStartupFilter as a IStartupFilter
  • That filter wraps the IApplicationBuilder in a SentryTracingBuilder so that we can intercept all of the calls to builder.Use<T>
• On each call to Use<T> our custom builder checks to see if the __EndpointRouteBuilder property has been set on the builder... which is a marker for UseRouting. As soon as that property is set, we know UseRouting has been called and we can then register our tracing middleware
• One other thing we do, before registering the middleware, is check that SentryAspNetCoreOptions.Instrumenter == Instrumeter.Sentry. If not, we don't register the tracing middleware... this would happen if folks were using OpenTelemetry rather than Sentry to auto-instrument their AspNET Core applications.

Caveats

Sentry.Google.Cloud.Functions is one of the few places I saw where I think users would still need to make the call to UseSentryTracing. There might be some other outlier scenarios like that but for the bulk of users, using vanilla ASP.NET Core, the developer experience should be way less complicated.

[bitsandfoxes]

Do I get that correctly: Since the UseRouting sets a flag and we check for that flag before forwarding to the InnerBuilder, Sentry will add the TracingMiddleware with the UseX that follows after UseRouting?
Which in practical terms doesn't matter much because there is always something coming after UseRouting?

[jamescrosswell]

Yeah this is what happens in the dotnet repo:

https://github.com/dotnet/aspnetcore/blob/8eaf4b51f73ae2b0ed079e4f8253afb53e96b703/src/Http/Routing/src/Builder/EndpointRoutingApplicationBuilderExtensions.cs#L58-L62

You can see they set that property immediately before calling UseMiddleware (which is then intercepted by SentryTracingBuilder). As soon as we see this property on the builder then, we know a call has been made to UseRouting and we can safely register our tracing middleware.

It shouldn't matter whether something comes after UseRouting or not... the way it sits at the moment, we would detect the call to UseRouting, the property would already have been set at that stage and we'd register both the UseRouting middleware and the UseSentryTracing middleware. If anything gets registered after UseRouting or not doesn't matter much then.

Initially I was making the call to InnerBuilder.Use(middleware) before checking for the existence of the property... just in case Microsoft ever changed the order in which they made the call to UseMiddleware and set the build property. However that would result in an extra (potentially unecessary) operation.

[bitsandfoxes]

I take it the Sentry.sln.DotSettings is not needed? Do we need to add it to the .gitignore?

This is awesome! More out-of-the-box, less documentation needed and one pitfall! With one PR! 🔥

[jamescrosswell]

I take it the Sentry.sln.DotSettings is not needed? Do we need to add it to the .gitignore?

That change was to add instrumenter to our shared dictionary actually... that file is where you can configure settings that are shared across the whole team, so it's supposed to be included in the git repo.