Reset unauthenticated request rate limit for IP upon authentication

Summary

The git command line program uses libcurl to issue HTTP requests. If a username is given in the URL of a remote, curl will first try an unauthenticated HTTP request, followed by a request with Basic auth headers included. This means that even if a git remote is configured with auth, there will always be at least 1 or 2 unauthenticated requests per fetch/push.

So when unauthenticated request rate limit is enabled on the Gitlab server, the effect is that authenticated users will not be able to issue more requests than configured for unauthenticated users.

This is not strictly a bug in the Gitlab rate limit implementation; it works exactly as advertised. However, because of the interaction with perhaps the most common client for Gitlab results in this poor user experience, it might make sense to accomodate that in the Gitlab server.

Steps to reproduce

1. Enable unauthenticated request rate limit and set to e.g. 5 requests per hour.
2. Clone a repository using https://<username>:<access_token>@<server>/<repo_path>
3. Issue a couple git fetch commands.

What is the current bug behavior?

After 2-5 successful git fetch commands, the command will return a 429 response.

What is the expected correct behavior?

The unauthenticated request rate limit is not hit and git fetch always returns a 200 response.

Possible fixes

I think it makes sense to disable the rate limiting (e.g. reset RateLimit-Observed) whenever a successful authentication has happened from an IP address. This will allow authenticated git users to fetch/push regardless of the unauthenticated request rate limit.