bring back the ability to specify peer in lightpush.send

[vpavlin]

This is a change request

Problem

Ability to configure peerId in LightPush.send was removed here: 81a52a8#diff-151faa41cf9f93c502df4cb30b090b41d2cadd6eba341246169e28dc7efdc666R100 in favour of peer-exchange (AFAIU)

I believe this should be revisited as the behaviour I am seeing is that js-waku will not really attempt to use different peer when send() fails and I as a user have no ability to change this.

There are multiple scenarios, but one I observed recently:

1. observe node dropping from libp2p.getConnections() list
2. call lightpush.send(..)
3. call fails with some error (for me it is usually Remote peer fault)
4. retry lightpush.send(..) - it keeps failing for unspecified amount of time/number of retries
5. the dropped node comes back and connection is reestablished
6. succeed eventually

I believe that if I would be able to specify a node (e.g. by randomly selecting from libp2p.getConnections() list, I could successfully send the message earlier - i.e. provide better user experience

Proposed Solutions

Bring back the ability to specify optional peerId in lightpush.send()

Notes

[fryorcraken]

To solve this, I expect js-waku to connect to 3 light push peers and send the message to all 3 peers to ensure reliability.

I am not in favor of getting the user to pass a peer id... where would it find the peer id? by collecting "connection" event and basically reimplementing the js-waku connection manager and peer store?

I thought @danisharora099 already implemented this for light push, am I incorrect?

The more advance version would be to also disconnect from peers who are the only one to report an error when using light push.

[danisharora099]

I thought @danisharora099 already implemented this for light push, am I incorrect?

While we introduced the ability to send requests to multiple peers in one of the PRs previously, the issue that tracks this exact work is #1463

If this is priority, we can do a PR for just lightpush (which is more straightforward), since other protocols like Filter would need some additional work to account for redundancy.

[fryorcraken]

If this is priority, we can do a PR for just lightpush (which is more straightforward), since other protocols like Filter would need some additional work to account for redundancy.

I'd prioritize for light push as it's easier and hopefully fix an issue that hacker might have.

@vpavlin do you want that to be scoped under the "presetnation readiness" epic?