.Net SDK release v3.0.0

[srprash]

This is a tracking issue for the changes going into the next major version release v3.0.0:

1. Fixed a typo in Reservoir [PR #62]:

Changes the class and methods from Reservior to Reservoir.

2. Update .net framework version to 4.5.2 [PR #101]:

Current SDK targets net45 as the TargetFramework for its projects. Since, the support for .Net Framework 4, 4.5 and 4.5.1 has officially ended, we plan to target the net452 version. This would break customers who are using the SDK with applications targeting net45.

3. Drop dependency on AWS SDK for .Net:

Current SDK depends on AWSSDK.Core and AWSSDK.XRay to fetch sampling configuration from service. This adds a fair amount of overhead to the SDK. We aim to make the X-Ray SDK lightweight with minimal footprint on customer applications. For the v3.0, the plan is to replace AWS SDK with HTTP calls as the mechanism to fetch sampling configurations.

4. Update IPlugin interface to use async methods:

Please refer to this PR for more details.

[jon-armen]

Re: Item 4: Update IPlugin interface to use async methods.

I don't see how this will be possible. I took a look into what it would take, and it leads down to AWSXRayRecorderBuilder().Build(), which is a core piece of initialization, and would require making much of the library async, including places where it is probably not intended. I see two possible paths, either A) Require initialization to be performed async (don't use a static initializer), or B) Keep NetCore3.1 and lower using the WebRequest route and net5.0 and higher can utilize the sync method on HttpClient. Any thoughts?

[jon-armen]

Re: Item 3: Drop dependency for AWS SDK for .Net.

I'm also not seeing how this will be possible for several reasons:

1. Extensive use of AWS SDK's Internal Logger class. (Our own logger could be implemented to decouple us if we strongly desired to remove the sdk)
2. RegisterXRayForAllServices and XRayPipelineCustomizer utilize AmazonServiceClient to register services from the AWS SDK. This functionality is, in my opinion a very desirable feature of this library. See Add generic constraint for RegisterXRay<T> such that T is constrained to IAmazonService #241 for an alternative change that would strongly type the constraint for RegisterXRay to enforce that only Amazon Service Client Interfaces are passed.