opt: optimize cluster identification

[tediou5]

Second attempt to close #2900

The first commit is meaningless; it simply renames cache_id to piece_cache_id

For the cache, everything is straightforward; it's just a matter of recording the corresponding relationships in the controller. However, things are a litter bit more complicated for the farmer. First, we check the identify message to see if the farmer is newly discovered and whether the fingerprint has changed. Based on the results, we decide whether to use the stream to fetch details.

The final commit is to ensure compatibility with previous approaches.

(I’m really sorry, actually, I finished it a long time ago, but I forgot about it and left it in a corner.)

Code contributor checklist:

• I have read, understood and followed contributing guide

[tediou5]

@nazar-pc additionally, during my actual development, this part of the code is not easy to test, and some scenarios are hard to cover(like farm FingerprintUpdated). At the very least, I need to start 3 components: nats, controller, and farmer/cache to do so. I was thinking maybe I could first submit a PR to extract the update logic for caches and farms and cover enough test cases?

[nazar-pc]

Thanks for contribution and sorry it took this long to read into it. This is certainly the right direction, but it will cause issues for the way maintenance of caches and farms is done (prevent loop with select! from actually looping quickly, which was carefully avoided before).

I only left comments on cache, but similar comments apply to farmer side as well.

I also don't fully understand why the thing that we try to address here was sort of added back at the end, I'm confused.

And please rebase changes after further updates (if any) and squash changes to the same part of the codebase, it'll be easier to review that way.

[tediou5]

Yes, let me adjust the code. Once I've completed my modifications, I'll take care of those annoying merges.

[teor2345]

This looks good to me, once Nazar's comments have been addressed

[tediou5]

No changes were made, just squash changes through rebase. Additionally, I removed ClusterCacheIdentifyPieceCacheBroadcast (also for the Farmer), they were reintroduced in a separate commit, and I simply dropped that commit. Nazar's comments will be addressed in subsequent commits.

[tediou5]

I’ve rearranged the commit order to make squashing easier later.

@nazar-pc I finished the cache implementation (it’s relatively straightforward), so you can review it for any potential issues.

91b3dd4: When a new cache appears, the system will collect the stream in the background and update KnownCaches once it’s done.

Before making changes to the farmer, perhaps I could submit a separate PR to parallelly add or remove farms? It doesn’t look too complex right now (and may even simplify the implementation).

[tediou5]

The farmer's work turned out to be simpler than I imagined, and it's also done.

1704ed5 is refactoring and moving code, with no actual changes.

75ddfe6 is the actual modification, but the logic after refactoring hasn’t changed much—it’s just split into two parts, with no other changes.

[teor2345]

These all seem fine to me, but Nazar knows this area much better than I do.

[tediou5]

Just rebase #3354