Breez SDK token support

[danielgranhao]

This PR adds support for token Payments on the Breez SDK API.

Main todos:

• Implement transaction to payments conversion
• Use spark address data if provided (sats vs tokens, amount)
• Handle errors
• Use sparkscan for syncing payments

Out of scope (left for separate PRs):

• Support 128-bit token amounts in bindings.
• Updating docs
• Spark addresses allow encoding if the recipient expects Bitcoin/specific token and an optional amount, effectively turning them into invoices. I propose we support this in receive_payment in a follow-up PR: Spark invoice support #212

[dangeross]

Do you think we'll hit issues with the u128 casting? Like with the max supply

[danielgranhao]

Do you think we'll hit issues with the u128 casting? Like with the max supply

Definitely! The idea is to address that in a separate PR. u128 is not natively supported by uniffi but we think it should be possible to expose it using custom types with custom lifting and lowering implementations

[danielgranhao]

PR is ready for review - still keeping as a draft just because it's missing the query ordering field. As a result, payments are currently not properly synced, but they can still be received or sent.

[roeierez]

Looks good!

[roeierez]

can you elaborate on this branch? What other options other than transfer transaction?

[danielgranhao]

There are 3 types of token transactions based on the type of input(s): mint, create, and transfer. The latter is the primary use case for Breez SDK, representing a transaction that spends the outputs of previous transactions.

For transfer transactions, Signed is an interim state, and means the operators haven't yet reached consensus. For mint and create, it's the final state, indicating that the funds are already spendable.

[danielgranhao]

I've added a commit that introduces the use of sparkscan to sync payments. Unfortunately, for now, there's no good way for us to use SparkScan to query pending ones (no batch option to query transactions by id, and querying 1 by 1 will likely lead to reaching api limits), so to do that, we still use the SO api. We may switch to a full sparkscan-based approach when batching is available.

Other noteworthy changes:

• Moved all model conversion logic out of models and into adaptors, separated into spark-sdk and sparkscan modules
• When sending a tokens payment, we insert a locally constructed pending payment in the storage (if we try to immediately query sparkscan it may not yet know of the transaction)
• Changed the default regtest env from loadtest to prod. We are forced to do this because it's the env that sparkscan runs on.

I still need to add tests and test more, but I would appreciate an initial pass of the current state of the PR.

[roeierez]

I very like that. I like the fact we sync pending payments for now separately, seems less vulnerable to sync issues.

[roeierez]

LGTM

[dangeross]

LGTM