This is only used when connecting, it doesn't need to be an argument of
the `ElectrumClient`.

TCP sockets with electrum servers require some non-trivial code to
reconstruct individual messages from the bytes received on the socket.

We process bytes in chunks, then reconstruct utf8 strings, and finally
split those strings at newline characters into individual messages.

We document that code, rename fields to make it easier to understand,
and add unit tests. We remove it from the TCP socket abstraction, since
this is specific to electrum connections.

We also change the behavior in case the socket is closed while we have
buffered a partial message: it doesn't make sense to emit it, as listeners
won't be able to decode it.

This is a pure 1:1 mapping from `connectionStatus`, there is no reason for
that duplication. Clients can trivially migrate or `map` using the
`toConnectionState` helper function.

We clean up the coroutine hierarchy: the `ElectrumClient` has a single
internal coroutine that is launched once the connection has been
established with the electrum server. This coroutine launches three child
coroutines and uses supervision to gracefully stop if the connection is
closed or an error is received.

Connection establishment happens in the context of the job that calls
`connect()` and doesn't throw exceptions.

We revert the introduction of a `CoroutineExceptionHandler` inside the
JVM socket code, as it shouldn't be needed anymore.

Otherwise we may be stuck in the `Connecting` state.

We just keep `getHeader` / `getHeaders` which can be handy.

On most RPC calls, we can gracefully handle server errors. Since we cannot
trust the electrum server anyway, and they may lie to us by omission, this
doesn't downgrade the security model.

The previous behavior was to throw an exception, which was never properly
handled and would just result in a crash of the wallet application.

We add an explicit timeout to RPC calls and a retry. If that retry also
fails, two strategies are available:

- handle the error and gracefully degrade (non-critical RPC calls)
- disconnect and retry with new electrum server (critical RPCs such as
  subscriptions)

The timeout can be updated by the application, for example when a slow
network is detected or when Tor is activated.

When connecting to an invalid address in tests on iOS, the error isn't
reported by the native socket which just hangs until the test times out.

We lower the timeout on the `connect` call, which previously had the same
value as the test timeout. We thus fail the connection attempt after
1 second and are able to reconnect to a different server.

The very low RPC timeout was flaky on iOS: because the clock used depends
on the actual dispatcher, it sometimes triggered only after receiving a
valid response from the server, which made the test fail. Setting it to
0ms ensures that the is immediately cancelled with a timeout exception
regardless of the dispatcher used.

We actually still need it until ktorio/ktor#3690
is integrated into a ktor release.

This was forgotten after e2e tests.

Since `withTimeout` runs concurrently, it may throw the timeout exception
after we've established the TCP connection, so we need to release it
if we can (if we have a pointer to it).

We can actually get it from the connection status, which simplifies the
way callers use those functions.