Extend the proxy to provide RateLimit headers

[jansenbe]

SharePoint API calls (Graph, REST, CSOM) return RateLimit headers whenever the application is about the consume its resource unit quota (see https://aka.ms/sharepoint/throttling). It would be good if the proxy allowed to mimic that by allowing the user to set the resource unit quota and then the proxy can track the request coming in, calculate the resource units for the request and verify if the quota is about to expire...if so, the proxy can start to include rate limit headers in the response.

.NET 7 has support for tracking and applying rate limits, see https://devblogs.microsoft.com/dotnet/announcing-rate-limiting-for-dotnet/

[waldekmastykarz]

This would be a great addition to use the new functionality and help developers test how their application is backing off when it starts getting rate limiting information.

@gavinbarron what do you think would be the best way to implement this?

[gavinbarron]

@jansenbe thanks for that info on the rate limiting, that's going to be very helpful!
AFAIK the resource unit concept of rate limiting also applies to the SPO apis that are exposed via Graph and it's a scenario we would need to account for sooner or later.

On the implementation question, I think we need to sit down and look at how we can break apart the traffic handing to allow for some kind of middleware setup which might allow for a plug-in style of extension to the tool where a plug-in might define the rate limiting behavior.

This could allow for complex configuration via config for the middleware while still providing an option for some lightweight usage scenarios for primitive failures etc as we currently provide.

[waldekmastykarz]

@gavinbarron could the first implementation become a part of our behaviors work along with other service limits? In the long run we could allow for more flexibility through plugins. What do you think?

[gavinbarron]

@waldekmastykarz yes! That's where my thoughts were going with this one.

[waldekmastykarz]

Duplicate of #210. We'll close this issue and track work status using #210 which is linked to the PR