Revisit strategy for host vs transport fallbacks

[paddybyers]

From a recent incident report:

It is evident that the current ably-js behaviour in the browser is too eager to remove the transport preference. There are real use-cases where a client that was previously successfully connected with a websocket is then unable to use a websocket and must fall back to comet; however this will be a very rare situation in comparison with the case that the same transport can be used. Therefore, the ably-js behaviour ought to be to continue to retry using a websocket for a longer time, or seek to determine a specific reason not to use it, before falling back to comet. A simple retry strategy that attempted to resume only using websockets would probably have recovered much more quickly in this case. We will review whether this requires a strategy/algorithm change, or if it is simply a matter of adjusting the parameters used to retain or discard the transport preference.

┆Issue is synchronized with this Jira Task by Unito

[VeskeR]

This is related to https://github.com/ably/ably-js/issues/1330 and transport 'no upgrade' work that has been done for ably-js v2 in https://github.com/ably/ably-js/pull/1645