reconnecting rpc: ensure poll order to avoid outdated subscription ID on reconnect

[niklasad1]

Originally posted by @lexnv in #1505 (comment)

TLDR, when a re-connection occurs the poll order of "pending futures" should wait until chainHead__follow returns then fetch the updated subscription ID.

Currently we have a hack to retry these a calls a few times.

[jsdw]

One idea offhand (but maybe not the best one!) is something like (I can't remember if I wrote this somewhere already):

1. Keep a "connection count" in the follow subscription thing, which is returned along with the subscription ID in the ready event and/or is available with every event (like the subscription ID might be).
2. When we get the data we want from the follow subscription, also note the current connection count at that time.
3. If some call that depends on data from follow subscription returns a DisconnectedWillReconnect, then go back to 2, but wait until the connection count increments before trying to do anything with the data.

So for a real example this might mean that we:

• get a subscription ID and note the connection count when we do
• call eg chainHead_v1_header(sub_id)
  • if the chainHead call return an error then loop around and try to get subscription Id again, waiting for an Id that has a connection count which is >=1 higher.

This should ensure that the follow subscription has reconnected at least once since we got the disconnected error, and isn't stale :)