feat: remove old version peer from peer store on fork

[driftluo]

1. Remove the behavior of joining the peer store when the session is established, and now only operate the peer store after the identify or feeler is successfully established
2. After the fork switch, the non-latest version of the node information will be slowly cleaned up, and no longer added to the peer store
3. Remove unnecessary runtime judgment RefCell

[keroro520]

Please add a test case to ensure that the staled peers are actually removed.

[keroro520]

If we don't remove the old version peers, will there be security issues?

[driftluo]

Please add a test case to ensure that the staled peers are actually removed.

check_purge uses the same remove API, I don’t understand what you want to test

If we don't remove the old version peers, will there be security issues?

There are no safety issues, there are efficiency issues

[keroro520]

Please add a test case to ensure that the staled peers are actually removed.

check_purge uses the same remove API, I don’t understand what you want to test

Okay, I see. Why do we not remove old version peers inside check_purge?

[driftluo]

Please add a test case to ensure that the staled peers are actually removed.

check_purge uses the same remove API, I don’t understand what you want to test

Okay, I see. Why do we not remove old version peers inside check_purge?

check_purge only judges the connectivity, not the version. During the fork switch, connectivity cannot filter out the nodes of the old client

[keroro520]

Please add a test case to ensure that the staled peers are actually removed.

check_purge uses the same remove API, I don’t understand what you want to test

Okay, I see. Why do we not remove old version peers inside check_purge?

check_purge only judges the connectivity, not the version. During the fork switch, connectivity cannot filter out the nodes of the old client

Thanks, I do not have any additional questions about it.

[doitian]

Not sure it is a good idea, since there's a very high probability that most the peers will switch to the fork.

[driftluo]

Not sure it is a good idea, since there's a very high probability that most the peers will switch to the fork.

This is just to clean up unnecessary node information so that it does not make meaningless broadcasts. There is no ban. If the node upgrades the client, it will be added back.

[quake]

This PR title and commit msg is easily misunderstood, suggest remove old version peer from peer store on fork

[doitian]

Please add a test case to ensure that the staled peers are actually removed.

check_purge uses the same remove API, I don’t understand what you want to test

If we don't remove the old version peers, will there be security issues?

There are no safety issues, there are efficiency issues

Could you expand this with more details? What's the performance impact if we do not purge the peer store on fork?

[driftluo]

Could you expand this with more details? What's the performance impact if we do not purge the peer store on fork?

The existing peer store rules are based on the detection of whether the session connection is successful. If it succeeds, the node information will be kept in the peer store.

In the fork version, the old and new networks can establish a session, but the corresponding protocol cannot be opened, and the network is isolated through the protocol version.

Formally because the session can be established, there will be a large number of invalid old version node information in the peer store. These data cannot be deleted by the current methods, and the dissemination of these invalid information in the network will result in a significant drop in the efficiency of node discovery

[yangby-cryptape]

bors merge=quake,yangby-cryptape

[bors]

Build succeeded:

• ci