wallet-http: put send transaction endpoints behind fund locks.

[nodech]

HTTP Endpoints that are responsible to directly sending transactions to the mempool (except send tx) - did not use fund lock to queue the requests to the wallet. What ends up happening if you are running automated scripts or send multiple requests at once - coins wont get marked as spent before another set of coins are selected. Resulting in conflicting transactions.

This makes sure every send* transaction:

• POST /wallet/:id/open
• POST /wallet/:id/bid
• POST /wallet/:id/reveal
• POST /wallet/:id/redeem
• POST /wallet/:id/update
• POST /wallet/:id/renewal
• POST /wallet/:id/transfer
• POST /wallet/:id/cancel
• POST /wallet/:id/finalize
• POST /wallet/:id/revoke

Uses fundlock until the coin is added to the txdb, before processing next HTTP request.

Hard Fee

Expose hardFee as an option to the HTTP. This can help users to specify the exact FEE they want to pay for transaction.

NOTE About TODOs.

// TODO: Add create TX with locks for used Coins and/or
// adds to the pending list.

When creating transaction (w/o sending), you run into the same issue. If you create 2 transactions at once, chances are they will use the same coins to fund them. There are two solution with existing tools for this:

• If createTX is SIGNED, we can add those transactions to the txdb w/o sending to the mempool.
• If createTX is NOT SIGNED, we can LOCK those coins, to ensure next createTX does not use the same coins to fund next one.
  This can be done by introducing new flags: insert - if signed but no broadcast - we can look at this flag and insert into txdb. And another flag: lock - if we are not signed (and of course that also means no broadcast), we lock the coins in non-permanently.

// TODO: Add abort signal to close when request closes.

Big wallets, with lots of coins, or big transactions that needs lots of coins can take a some time to craft transactions before broadcasting. We get compounding effect when we use fundLocks where multiple requests are also queued.
So allowing new request parameter abortOnClose can work by making sure that transaction creation is done before request closes. If request closes and transaction already was being sent, it will do nothing.

[coveralls]

coverage: 68.628% (-0.02%) from 68.65% when pulling e49a8fc on nodech:http-races into 61ae19c on handshake-org:master.

[rithvikvibhu]

is passphrase needed here for consistency?

[nodech]

This works because the wallet is unlocked at this stage. (Wallet is locked in the afterEach)
I will just add comment.

[rithvikvibhu]

• The test expectedly fails on master with double spend errors 👍
• searched for all wallet.send() calls, none passed passphrase as 2nd arg
  LGTM