Add subcrate which impls a simple SPV client from Bitcoin Core RPC

[TheBlueMatt]

This is still very much a WIP, and I want to reduce the dependencies to at least not rely on hyper as well as actually implement the REST-based client, though doing so should be trivial.

This adds a new subcrate lightning-http-blocks which is designed
to make it easier to get up-and-running by removing the effort of
building an SPV client and fetching the chain.

Instead of building a P2P client (and all the address management
that entails), this focuses on building a trivial SPV client which
can fetch from several instances of an abstract BlockSource. Then,
we provide two example BlockSource implementations that can fetch
from Bitcoin Core's RPC interface and Bitcoin Core's REST interface.

The code here is taken with heavy modifications from
rust-lightning-bitcoinrpc.

Addresses #627.

[TheBlueMatt]

Still a bit raw in terms of code quality and still need testing, but its a thing, and worth at least a glance-over.

[codecov]

Codecov Report

Merging #614 into master will decrease coverage by 0.00%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #614      +/-   ##
==========================================
- Coverage   91.12%   91.11%   -0.01%     
==========================================
  Files          34       34              
  Lines       20544    20544              
==========================================
- Hits        18720    18719       -1     
- Misses       1824     1825       +1     

Impacted Files	Coverage Δ
lightning/src/ln/channelmonitor.rs	95.50% <100.00%> (ø)
lightning/src/ln/functional_tests.rs	97.02% <0.00%> (-0.02%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9098240...197e244. Read the comment docs.

[valentinewallace]

Haven't dived into the details yet but overall the structure looks good and makes sense!

I think the commits could be split up a bit more though. If you're busy with language bindings I don't mind taking on this task. The following split makes sense to me, in order:

1. common utilities used between REST client and RPC client
2. the HTTP client
3. the REST client (or swap 2 and 3, or possibly combine them)
4. BlockSource + its implementors + the structs that only BlockSource/its implementors use
5. The AChainListener + its implementors
6. The MicroSPVClient and its static functions

[valentinewallace]

Also -- I think this could benefit from some example usage similar to what's in lightning-net-tokio: https://github.com/rust-bitcoin/rust-lightning/blob/master/lightning-net-tokio/src/lib.rs#L17 through line 62.

[TheBlueMatt]

@valentinewallace if you feel up to it feel free to take this over! Or @jkczyz if so inclined.

[jkczyz]

@valentinewallace if you feel up to it feel free to take this over! Or @jkczyz if so inclined.

FYI, I've taken on this work and am currently working on some necessary refactoring to BlockNotifier and ChainListener.

Regarding eec4beb, the refactoring mentioned above may alter this in some way. I'm looking into that now and will ping you with any questions that I may have.

[jkczyz]

FYI, I've taken on this work and am currently working on some necessary refactoring to BlockNotifier and ChainListener.

Here's the PR rebased on #649 using BlockNotifier instead of AChainListener: https://github.com/jkczyz/rust-lightning/tree/pr-614-rebased.

[TheBlueMatt]

Superseded by #763.