Fix previous shard info publishing when changing community shard

[igor-sirotin]

Ideally we should unsubscribe when we're no longer interested in receiving messages or publishing to the topic.
So in this flow you describe:

- Change community shard to 256
- At this point we unsubscribe from shard 128.
- And then send the new shard info. But we should send it on previous shard, so we do it on shard 128.
⚠️ And this is how we call Publish without being subscribed. And it seem to be working fine, 1 peer found.

We need to switch the order of unsubscribing and sending the previous shard info.
I do also see this flow prone to errors because it's possible that publishing the new shard might fail. So perhaps the way to go is: Publish the new shard info. Confirm that the message is received by a storenode (this is done with the message verification logic that @kaichaosun implemented, and only then, unsubscribe from the shard. (Maybe this verification and unsubscribe attempt could be done async?)

Originally posted by @richard-ramos in #5759 (comment)

[kaichaosun]

Not sure how change shard works for community, if we have a big community, changing from shard 128 to shard 256 (or any other shard), users in community get the changing shard message at different time, right?
We probably need to subscribe both shards for a certain period, for example 10 days. After that, only new shard will be supported, and messages through old shard will not be seen by others.

[igor-sirotin]

We probably need to subscribe both shards for a certain period, for example 10 days

In theory this shouldn't be needed. Even when changing the shard immediately, members will be able to fetch the shard info from the storenodes on the old shard, then switch to the new shard and fetch everything here again from the point when the shard was changed.

Though such algorithm is not implemented as well 😄
There's probably only 1 timestamp of "last sync with store nodes" and it's not rewinded when shard change was detected.