feat: Add Sb-Forwarded-For header and IP-based rate limiting

[jnschaeffer]

What kind of change does this PR introduce?

This PR adds support for IP address forwarding using a new header, Sb-Forwarded-For, optionally gated by GOTRUE_SECURITY_SB_FORWARDED_FOR_ENABLED. When this feature is enabled, both utilities.GetIPAddress and rate limiting will use the first value of the Sb-Forwarded-For header as the IP address/rate limiting key.

If the feature is disabled or the Sb-Forwarded-For header contains an invalid value, Auth will fall back to existing behavior.

What is the current behavior?

There are currently two paths along which users are likely to use IP address information. The first is IP tracking (e.g., logging, MFA challenge validation, and CAPTCHA challenge validation). The second is rate limiting. Both of these follow slightly different logical paths, relying on the X-Forwarded-For header explicitly in the former case and a separate rate limiting key header in the latter.

The presence of these two paths results in some friction for users. X-Forwarded-For can be (and frequently is) rewritten by proxies or otherwise spoofed, and there is no guarantee that a rate limiting key in the rate limit header is an IP address.

What is the new behavior?

The API uses a new middleware, sbff.Middleware, that parses the Sb-Forwarded-For header and inserts it into the request context if GOTRUE_SECURITY_SB_FORWARDED_FOR_ENABLED is true. Consumers of the Sb-Forwarded-For header can use sbff.GetIPAddress to retrieve the parsed IP address.

utilities.GetIPAddress will prefer the result of sbff.GetIPAddress as the end-user IP address if the feature is enabled and the Sb-Forwarded-For header contains a value value. Similarly, Auth will use the end user IP address as determined by sbff.GetIPAddress as the rate limiting key under the same circumstances.

If the feature is not enabled or the Sb-Forwarded-For header is absent or otherwise invalid, Auth will default to existing/legacy behavior.

[coveralls]

Pull Request Test Coverage Report for Build 20444605904

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 63 of 66(95.45%) changed or added relevant lines in 4 files are covered.
• 30 unchanged lines in 1 file lost coverage.
• Overall coverage increased (+0.2%) to 68.686%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
internal/api/api.go	5	8	62.5%

Files with Coverage Reduction	New Missed Lines	%
internal/indexworker/indexworker.go	30	80.84%

Totals
Change from base Build 20307749740:	0.2%
Covered Lines:	14696
Relevant Lines:	21396

---

💛 - Coveralls

[cstockton]

Looks good to me aside from a small nit on TODO code