feat(relay): Operation-based rate limiting + Resolve most recent

[afterburn]

Summary
This PR replaces current rate limiting with an operation-based configuration that maps directly to the relay's three core operations: publish, resolve, and resolve_most_recent.

Configuration Example

[relay]
[[relay.rate_limits]]
operation = "resolve"
quota = "10r/s"
burst = 20

[[relay.rate_limits]]
operation = "resolve_most_recent"
quota = "2r/s"
burst = 5

[[relay.rate_limits]]
operation = "publish"
quota = "2r/s"
burst = 10
whitelist = ["127.0.0.1", "192.168.1.0/24"]  # optional, both ips and subnets supported

Operations in this toml file automatically map to:

• publish → PUT requests (publishing records)
• resolve → GET requests without most_recent=true (cached lookups)
• resolve_most_recent → GET requests with most_recent=true (DHT queries)

If no config.toml file is present, system will use defaults, so this is not a breaking change.

[SeverinAlexB]

Need to do a second round later

[afterburn]

@SeverinAlexB resolved your feedback:

• Removed kb, mb, gb quota units, now always uses either r/s or r/m as requested
• Changed default rate limits to something saner
• Added behind_proxy flag in config toml, which allows users to respect/ignore proxy headers
• Cleaned up IP extraction, only happens once per request now
• Added operation 'Index' so users can specify rate limiting for root path

[SeverinAlexB]

Two comments, otherwise looks good.

In the Pubky Core team, we have a convention on how to format PR title. We stick to the conventional commit format.

So for this PR, the title could be: feat(relay): Operation-based rate limiting + Resolve most recent

[afterburn]

@SeverinAlexB

• If no rate limits are defined in config.toml, rate limiting will be disabled completely
• Added Index to Operation enum so calling GET http://0.0.0.0:6881/ doesn't trigger the incorrect rate limit
• Added resolve_most_recent_enabled flag so users have the ability to completely ignore the most_recent=true query parameter (defaults to false for backward compatibility)

[SeverinAlexB]

One NIT, otherwise good to go

[SeverinAlexB]

Actually, should this add the most_recent option to the pkarr client too? You are just adding it to the relay in this PR?

[SHAcollision]

Great progress! Left a few minor comments and nits.

[afterburn]

@SeverinAlexB @SHAcollision Restored DHT rate limiting that was previously removed. Since the DHT can be accessed directly, keeping rate limiting in place is necessary. The implementation is now fully backward compatible. Existing [rate_limiter] configurations continue to work as before. New [dht_rate_limit] and [http_rate_limit] options are opt-in. By default, it falls back to the legacy IP-based limiter unless one of the new configs is defined. Also added a comprehensive test to cover the new behavior and ensure backward compat.