Add compact block filter client via Kyoto

[rustaceanrob]

Description

Adds a compact block filter backend via Kyoto. Should remain a draft PR until we have an official release for bdk_kyoto

Notes to the reviewers

I will need help writing tests, although I am not sure we need to test the node syncs, only that the node can be built and ran for a couple seconds.

Architectural notes:

Most of these decisions are a product of either kyoto or bdk_kyoto and passed through the bindings:

• Users may build a LightClient and LightNode with a namespace level function that takes node configurations.
• To start syncing, the user must run a LightNode in the background. I expose an method on the namespace level function called run_node that moves the process to a different OS thread and returns immediately
• Syncing is simple, as the LightClient simply returns a wallet Update when calling update. This can be applied directly to the wallet.
• At any time, a LightClient may broadcast a transaction
• At any time, a LightClient may shutdown the node
• A LightClient may also add more addresses (scripts) to watch with watch_address. When a user reveals a new address, it should be added to the node. Most of the time, however, the node will already be aware of the script, as bdk_kyoto peeks ahead of the last revealed index.
• The node issues a number of events and warnings, which are deferred to the NodeMessageHandler trait. The idea is the application will define arbitrary behavior, from writing to a log file to updating user interface components.

Changelog notice

• Add a compact block filter chain source

Checklists

All Submissions:

• I've signed all my commits
• I followed the contribution guidelines
• I ran cargo fmt and cargo clippy before committing

New Features:

• I've added tests for the new feature
• I've added docs for the new feature

Bugfixes:

• This pull request breaks the existing API
• I've added tests to reproduce the issue which are now passing
• I'm linking the issue being fixed by this PR

[thunderbiscuit]

Just for fun:

Binary size when including Kyoto, building the aarch64 binary on macOS using the release-smaller profile (libbdkffi.dylib): 9.7MB
Binary size without Kyoto, building the aarch64 binary on macOS using the release-smaller profile (libbdkffi.dylib): 8.6MB

Not bad at all for what is likely to be one of the most popular clients one day.

[rustaceanrob]

Awesome thank you for checking that out. Props to rust-bitcoin and tokio for keeping things tidy.

[rustaceanrob]

Objects cannot currently be used in enum variant data

You can imagine my disappointment with this error message after hacking on this PR again. I'm trying to express the new Event<K> from bdk_kyoto but it returns objects like Update (FullScanResult) as a variant. We can return more primitive types as variants, but then we can't express the Update. It doesn't make sense to express an event as anything else than an enum, as only one variant is used at a time to express the event.

It's been so long but maybe that is what I had in mind with the callback interface in the first place lol. Open to new ideas, but until we can return objects from enum variants I think we may have to stick with callbacks...