Use delegate wallet to determine content node for listen tracking

[raymondjacobson]

Description

What is the purpose of this PR? What is the current behavior? New behavior? Relevant links (e.g. Trello) and/or information pertaining to PR?

Purely additive change and all 3 components can be released individually.

The gist of how this works:

• Every time a content node sends a listen req. to identity, pass along a signed message & timestamp
• On identity if a signature is present on a listen req. (clients won't be sending this), compare the signer against the known set of content node delegate wallets. Use that comparison to establish that the IP address of the content node is known
• Use that IP to whitelist the rate limiting functions

Two optimizations to make the above work better:

• Content nodes won't sign a new message every time they record a listen (there are a lot). Instead, we re-use the signature so long as it's valid (5 minutes)
• Identity service doesn't verify the signature every time -- only if the IP is unknown AND there is a signature present on the request. This means that after the first time a content node sends a signature, identity remembers the IP and passes rate limits based on that

Tests

List the manual tests and repro instructions to verify that this PR works as anticipated. Include log analysis if possible.
❗ If this change impacts clients, make sure that you have tested the clients ❗

1. Added a unit test for the isFromContentNode check
2. Manually tested locally and ensured that listens began getting "whitelisted" as the signature was matched
   ...

❗ Reminder 💡❗:
If this PR touches a critical flow (such as Indexing, Uploads, Gateway or the Filesystem), make sure to add the requires-special-attention label. Add relevant labels as necessary.

[dmanjunath]

direction is good, had a few questions

[dmanjunath]

Okay this looks pretty good!

[piazzatron]

Looks good to me - clever design. Just a few nits

[dmanjunath]

Looks good!

[SidSethi]

good call on caching the signature!