chore: add benchmarks

[vasco-santos]

This PR adds a benchmark setup to stress test a rendezvous server and gather some metrics (CPU Usage, Memory Usage and Response Times).

With the benchmark setup, there is also a script to run a benchmark with different operations and scales. These operations and scales scenarios are documented in a README file, with the results in the side and some notes on them.

In overview, a single rendezvous server seems to operate in an acceptable fashion when dealing with operations of 100 clients at the same time. However, we should probably try to avoid getting to such numbers otherwise some requests might have unacceptable time responses (this happens in a local setup running 100 clients in the same process, but things would be better when in a "real environment" as the clients would not be bottlenecks). A more extensive summary of the results is included in the README file for the benchmarks.

We can look into 2 other things in order to improve the performance of the system:

1. Discover does not wait to update the cookies table before responding the discover query

• If the cookies table update fails for some reason, the follow up discovery query would return the same peers
• This might create some inconsistencies, but the same peers will likely be returned when they update their registration. So, the client side already needs to take this into account.
• This might cause redundant discovery requests in case of error
  • Not guaranteed as the discovery query is ordered by the registrations with more validity, so it would be possible to actually receive some new results

2. Number of connections in the Database Connection pool

• According to some statements regarding the Database Connection pool size, the maximum size of this pool should be 15-20 for a generic machine. We can look into increasing this a bit, as I have seen some claims of people using 100. The more connections we have, the more memory consumption we will have. As there will be a lot of rendezvous clients connected over time, I feel that we should not increase this a lot, unless we will be using machines powered with lot's of memory. This is configurable, so I would just focus on finding a good default for now.

Needs:

• feat: rendezvous protocol initial implementation #6 this is on top of feat: rendezvous protocol initial implementation #6, so only the last commit should be considered