feat: add resource manager for separate DHT libp2p host

[aschmahmann]

Seems like we need a separate resource manager for the DHT host if it's separate. For now I just reused the limits, but that's obviously not right since that would put the default memory usage at 0.85 * 2 of total memory and 0.5 *2 of total FDs.

Some notes:

• We should be able to significantly throttle inbound streams and connections
• We could separate various flags (connmgr, memory, fd) flags for the new host if we wanted, but either way we need some sensible default percentages to allocate
• For some reason running before Add peering support #35 does not result in resource manager errors from the accelerated DHT client (perhaps related to smart dialing?), but this change seems needed anyway

Thoughts?

[hsanjuan]

Have we established that running 2 hosts is better? I keep forgetting that there are 2. We should settle on one or 2.

[aschmahmann]

Have we established that running 2 hosts is better? I keep forgetting that there are 2. We should settle on one or 2.

I think so, but would like @ns4plabs or @acejam to confirm when they have a chance.

[aschmahmann]

The changes here might be overkill and is pretty guesstimated, just wanted something other than disabling the resource manager for people to test with.

Recommendations appreciated 🙏

[BigLep]

2024-01-05 conversation:

1. In the ipfs.io rainbow deployment, are we seeing these errors? (@ns4plabs said no but we should double check here)
2. test whether shared DHT has better performance (looking at CPU/memory utilization, TTFB) on the ipfs.io gateway staging

Wny this matters:
If we are seeing errors, then routing resolution will be worse.

If we don't see any errors here, then the priority of this goes down.

Note that we'll only see the errors closer to node startup.

Next step: Get @aschmahmann access to logs and a record of what commit was deployed when.