This actually hurts performance because the batched response has to be
bueffered on the bitcoind side, as @TheBlueMatt explains at
romanz#373 (comment)

Instead, send multiple individual RPC requests in parallel using a
thread pool, with a separate RPC TCP connection for each thread.

Also see romanz#374

The indexing process was adding transactions into the store so that
prevouts funded & spent within the same batch could be looked up via
Mempool::lookup_txos(). If the indexing process later failed for any
reason, these transactions would remain in the store.

With this change, we instead explicitly look for prevouts funded within
the same batch, then look for the rest in the chain/mempool indexes and
fail if any are missing, without keeping the transactions in the store.

Previously, if any of the mempool transactions were not available
because they were evicted between getting the mempool txids and txs
themselves, the mempool syncing operation would be aborted and tried
again from scratch.

With this change, we instead keep whatever transactions we were able to
fetch, then get the updated list of mempool txids and re-try fetching
missing ones continuously until we're able to get a full snapshot.

- Reduce logging level for bitcoind's JSONRPC response errors

  These can happen pretty often for missing mempool txs and do not
  warrant warn-level logging. Unexpected RPC errors will bubble up and
  be handled appropriately.

- Add more verbose logging for mempool syncing

Keep RPC TCP connections open between sync runs and reuse them,
to reduce TCP connection initialization overhead.

Following Blockstream#89 (comment)
and Blockstream#89 (comment)