Defend against eclipse attacks with ALLOW-list support

[BigLep]

Done Criteria

1. A go-libp2p operator/application has a mechanism to ALLOW-list limits for specified IP addresses that trump other limits.
2. There is accompanying documentation on how to use this functionality.

Why Important

This can be a useful mechanism for protecting against eclipse attacks.

Notes

1. I'm intentionally preferring allow/deny list verbiage over white/blacklist.
2. A "design" covering the developer experience should be posted first before we jump into impelementation.
3. We can only allowlist on IP address (not peer-id) because the accept/reject decision happens before we read enough of the stream to determine peer id.
4. An eclipse attack would be mitigated by setting a default incoming connection limit to 0, but then ALLOW-listing certain trusted IP addresses.
5. Basic static allow-listing can also be accomplished at the OS level with "firewall rules" that DENY all incoming requests but ALLOW requests for certain trusted IPs. The advantage of doing this in libp2p itself is it makes it easy to build an intelligent application. For example, an application could observe that certain nodes have been reputable for a sustained period of time and thus move them to the trusted set of "ALLOW list" IP addresses so already have this set even if an eclipse attack occurs and default incoming limits need to be set to zero.
6. Any abilities developed here should be propagated to Guide for how to respond to resource exhaustion attacks docs#153
7. In terms of rolling out this change

• We'd like to see it used in PL infra (e.g., IPFS bootstrapper or gateway, which also means propagating the change into Kubo).

[BigLep]

Reopening because there is followup work to do per #47

[MarcoPolo]

Reopening because we need to still add some docs around this