Configurable client

[bucko13]

Description

With a recent release adding mempool.space support (#347), a few issues came to light, which this PR seeks to address.

Problems

Rate Limiting in mempool.space

The biggest one noticed in #364 was that recent rate limiting implemented on mempool.space's main production endpoint caused significant performance degradation. Throttling was already an issue with blockstream for which we added a delay to avoid hitting the rate limit, but this may not be enough.

Hard to change client

Unfortunately the way to change the client had to come from unchained-bitcoin, which is really inconvenient and probably not the right long term place for this.

Clumsy API

Every api call had to pass in the network and client info even though once the wallet is setup, this doesn't change. Would be nice to just get this from the store and be done.

Mempool not a perfect drop-in replacement

One of the api calls (getFeeEstimates) was not quite a drop-in b/w mempool and blockstream. So this might've been broken as well

Hard to make changes

If there are any changes in the future (immediate example: mempool is going to have a websocket option for using as a wallet backend), it's not easy to update the client without backwards incompatible changes.

Solution

• This PR first moves all the client relevant code into their own module (c90211ddee4de7fce9e7bcdcea5628cd31bccabe).
• Then it introduces a new BlockchainClient class (d3201c2), which once initialized with the connection details shares an api no matter what client you're connecting with
• This class supports bitcoind, mempool, or blockstream. This moves the connection info from unchained-bitcoin. Longer term, I think this should exist in its own package to be maintained separately. An external package shouldn't dictate what the public client endpoint is, but it makes sense to have a unified (and well tested) package for communicating with the blockchain. The consumer (in this case the caravan coordinator) can decide which it wants to use when initialized and just go from there.
• the UI is still very tightly coupled with redux, so this PR adds some code f591a0e to the store and actions to set the client and get the client (based on other client settings in the store) for components to use as needed.
• TypeScript and tests. TS isn't as useful as it could be without many TS consumers but it's a start.
• The class also has built-in, configurable support for throttling if necessary to avoid rate limiting in a way that should be easy to turn on and off
• the update in clientActions shows how easy it should be to support multiple clients. It's one line now to change the default public b/w blockstream and mempool and eventually we should easily be able to support either and leave it up to the user.

Does this PR introduce a breaking change?

• [ ] Yes
• [x] No

Does this PR fix an open issue?

• [x] Yes
• [ ] No Fixes #364

[carlaiau]

Is there an ETA of this getting merged into main?

[carlaiau]

Blockstream API broadcast accepts raw tx not JSON object. I am experiencing a CORS policy failure on preflight as well as the broadcast itself. Copying the HEX and posting it via CURL works successfully.

public async broadcastTransaction(rawTx: string): Promise<any> {
    try {
      if (this.type === ClientType.PRIVATE) {
        return bitcoindSendRawTransaction({
          hex: rawTx,
          ...this.bitcoindParams,
        });
      }
      return await this.Post(`/tx`, { tx: rawTx });
    } catch (error) {
      throw new Error(`Failed to broadcast transaction: ${error.message}`);
    }
  }

[bucko13]

Added in the caravan monorepo now live as of d1d169