Add initial impl of PartitionedRateLimiter.Create

[BrennanConroy]

Adds the PartitionedRateLimiter.Create method and the other types necessary to implement it.
#65400

Some more work will need to be done once #67020 is merged so we can properly handle replenishing rate limiters.

Additionally, fixed a bug (in concurrency and token bucket) with cancellation when disposing the limiter and when adding new requests to the queue. Found while writing a cancellation test for the PartitionedRateLimiter.

CreateChained and TranslateKey are not included in this change.

[dotnet-issue-labeler]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[ghost]

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Adds the PartitionedRateLimiter.Create method and the other types necessary to implement it.
#65400

Some more work will need to be done once #67020 is merged so we can properly handle replenishing rate limiters.

Additionally, fixed a bug (in concurrency and token bucket) with cancellation when disposing the limiter and when adding new requests to the queue. Found while writing a cancellation test for the PartitionedRateLimiter.

CreateChained and TranslateKey are not included in this change.

Author:	BrennanConroy
Assignees:	-
Labels:	area-System.Threading
Milestone:	7.0.0

[halter73]

Since #67020 is merged, can we do something? Or are we going to leave that as follow up for preview5? I guess we can announce it with the caveat that it only works for a statically bounded number of partitions. Partitioning by username for example would not be advisable.

[halter73]

Can we file issues for the any TODOs we think are worth following up in the .NET 7 timeframe? I think these probably qualify. I think we might want to add public API to make this interval configurable.

[halter73]

I think we're going to have to catch any exceptions now that we rely on the loop continuing. It's unfortunate that we cannot log it, and this stops any exception from showing up as an UnhandledException. It's tempting to use ExceptionDispatchInfo.Capture and dispatch the throwing of the exception to a threadpool thread.