fix: Revert "feat: shard aware peer management (#2151)"

[Ivansete-status]

Description

This reverts commit dba9820.

We need to revert this commit because
the waku-simulator stopped working. i.e. the nodes couldn't establish connections among them: https://github.com/waku-org/waku-simulator/tree/054ba9e33f4fdcdb590bcfe760a5254069c5cb9f

Also, the following js-waku test fails due to this commit: "same cluster, different shard: nodes connect"

This approach is preferred because the #2151 PR was quite complex and I think is better to take a temporary
step back, re-think and re-test it until we make sure the waku-simulator and all js-waku tests work.

[github-actions]

You can find the image built from this PR at

quay.io/wakuorg/nwaku-pr:2312

Built from fa7218c

[gabrielmer]

LGTM, thanks so much!

[NagyZoltanPeter]

LGTM! Thanks for going after steadily.

[alrevuelta]

Mind elaborating on why this is causing issues? I would like to fully understand where the problem is before reverting. Not sure "the waku-simulator stopped working. i.e. the nodes couldn't establish connections among them" is enough as a reason.

waku-simulator is not using cluster-id, perhaps that can be related. that may be impacting peer management strategy. But ofc, even without that, it should work.

created a tracker for that, slightly related.
waku-org/waku-simulator#16

[Ivansete-status]

Mind elaborating on why this is causing issues? I would like to fully understand where the problem is before reverting. Not sure "the waku-simulator stopped working. i.e. the nodes couldn't establish connections among them" is enough as a reason.

waku-simulator is not using cluster-id, perhaps that can be related. that may be impacting peer management strategy. But ofc, even without that, it should work.

created a tracker for that, slightly related. waku-org/waku-simulator#16

Thanks for the comments @alrevuelta !

This is precisely the actual reason: we cannot deliver things that are not backward-compatible.

That change made the current waku-simulator setup fail and this shouldn't happen, at least in an abrupt way.

All the breaking changes should be properly documented and informed. If we make a big change we need to ensure a smooth transition to users in the same way we keep deprecated wakunode2 parameters for at least two consecutive releases.

I didn't test this issue in wakuv2.test but it will likely happen as well because the wakuv2.* fleets don't set any cluster-id either.

Another reason to justify that "revert" decision is the following issue from js-waku tests: waku-org/js-waku#1765
EDITED: that was the js-waku test that failed: "same cluster, different shard: nodes connect".

Let me know if need more details :)

Cheers