Remove BandwidthCommunity

[drew2a]

This PR removes the BandwidthCommunity and closes #7336. It also contains a migration for removing bandwidth.db files.

I've decided to leave the BandwidthCrawler as an example of a simple crawler for Tribler, for the next generation of developers or PhD students.

PR / scripttest_draft / run (pull_request_target) is failing because, due to security reasons, the content of YML files is always taken from the target branch. Therefore, the checks for the current PR use the old (unchanged) scripttest.yml. After merging, this check should be correct.

Closes #5212
Closes #4939
Closes #4255
Closes #3731

[drew2a]

@egbertbouman, I'm requesting your review as it turns out that the BandwidthCommunity was intertwined with the TunnelCommunity. I've tried to be as careful as possible, but it's hard to grasp all the logic from TunnelCommunity and verify on my own that my changes are correct. However, all tests have passed, and anonymous downloading is working (I've tried it both on new downloads and existing ones).

[egbertbouman]

Looks good to me. A couple of things to note:

• BalanceRequestCache can be removed, as well as the cache check in should_join_circuit.
• Since messages/cells have been removed, but old peers are still sending these messages, I'm guessing there is a lot of log spam now.
• While the network updates to the new code, there will be a bias toward people that are running the old code (e.g. new peers only compete for random slots, whereas old peers compete for all slots). Not really a problem anyway.

[drew2a]

I've removed BalanceRequestCache and the cache check in should_join_circuit: d6edc77 (I'll swap the commits before merge).

Since messages/cells have been removed, but old peers are still sending these messages, I'm guessing there is a lot of log spam now.

Yes. But as we've seen that the network updates to the new version quite quickly (it takes a couple of weeks), then it is probably worth it to wait without any temporary warning suppression.

While the network updates to the new code, there will be a bias toward people that are running the old code (e.g. new peers only compete for random slots, whereas old peers compete for all slots). Not really a problem anyway.

Agreed. Also, I'll note here just in case, that I've increased the random slot count from 5 to 20 as it seems fair to keep the same amount of slots as before (random_slots (5) + competing_slots (15)).