Ability to selectively ignore remote trace data

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Is your feature request related to a problem? Please describe the problem.

I have a service based on ASP.NET Core which exposes multiple API areas. Some of those are intended for usage internally within our company's ecosystem while others are publicly accessible. This is running in Azure on App Service, using Application Insights to gather distributed traces.

Some external parties integrating the publicly accessible surface send trace headers which are then used by the application to compose distributed traces. However, since this aggregation is done by the external system, it affects our distributed traces in ways that we don't find useful. I'd like to prevent this from happening.

### Describe the solution you'd like

I have checked the implementation and my understanding is that the trace data are processed quite early in the request processing so I cannot use a middleware or filter to do anything about this.

I have noted that the trace data are accessed through `DistributedContextPropagator` sourced from the DI container. My thinking is that I could register my own `DistributedContextPropagator` implementation that would not extract remote trace information for specific request paths. My understanding is that `HttpContextAccessor` should be set up for the request by this point so I can access the request path there.

Is this a sensible approach? Are there better/alternative approaches available?

Besides that, would it be feasible to support this directly in the framework or make supporting this case simpler? For example, I can imagine an extension point such as `IRemoteTraceFilter` that would receive the `HttpContext` and the resolved remote trace data and decide whether remote trace data should be accepted and possibly which parts. That way, I could avoid `HttpContextAccessor`, having to implement the `DistributedContextPropagator` interface and also isolate myself from how the `DistributedContextPropagator` is registered within the framework.

### Additional context

I am aware of other approaches such as
1. Filter out the headers on the edge (e.g. a reverse proxy/load balancer).
It would be complicated for me to determine which requests to which APIs should have the filter applied. I prefer code-level solution here, the load balancer is only aware of the service as a whole, not its parts and their semantics.
2. Make external parties _not_ send the trace headers.
I don't think I could make this happen, unfortunately.
3. Disable remote tracing altogether.
I can't do this as not all APIs are public, some of them are used to send messages in the opposite direction (from internal to external systems) where distributed traces are invaluable.