HttpClient should propagate parent context even when Filter or Sampler is in play

[cijothomas]

1. For HttpClient (.NET Framework) via HttpWebRequest
   As mentioned here, HttpWebRequest instrumentation must propagate Current context #1445 (comment), the instrumentation should propagate the context from parent, when the request itself is filtered out. Filtering/Sampling causes the activity to be not created/recorded, but there might be a parent context, which must be propagated downstream, otherwise downstream services thinks they are root and starts generating fresh TraceIds, leading to broken traces.

2. For HttpClient (.NET Core)
   As this library has legacy instrumentation, there is no situation causing Activity to be null, so propagation is almost always correct. The exception is the Filter API, which is used to short-circuit the DiagnosticSourceSubscription. This means, whenever Filter is applied, no callback is fired, and hence no context is propagated. This would NOT lead to broken trace always, as HttpClient has built-in TraceContext propagation. But it does not work if propagator is custom. Also the baggage won't be propagated natively by HttpClient. This can also be an issue, but not as bad as broken trace when downstream service starts fresh TraceId.

3. For GrpcClient - not an issue, as grpcClient relies on underlying HttpClient to handle propagation in most cases. The exception is when downsteam is suppressed, and in that case grpcClient is propagating correctly now, as there is no Filter option available in grpcClient. Once it is added (Add Filter options to gRPCClient instrumentation opentelemetry-dotnet-contrib#1781), we need to ensure it doesn't prevent context propagation.

[cijothomas]

1 is handled by #1562