Restructured blinding + custom messages + keep vectors

[Egge21M]

Description

This PR addresses a couple of things that were discussed in the past: Sorted outputs when swapping, as well as custom outputs. I always felt like the old BlindingData type was not ergonomic enough, so I restructured some of the blinding types and logic, moved them to their own Class and Interface. These changes are so closely related, that they became a single PR (that got a little out of hand, sorry...).

Changes

• BlindingData is now called OutputData. It holds all the data required to construct an Output from a BlindedMessage and a Signature
• OutputData (form. BlindingData) is no longer an Array, but now represents a single encapsulated future Proof
• Wallet methods now accept a new option outputData that implements the OutputDataLike Interface. Using this consumers of the library can opt out of the automatic creation of outputs and supply their own logic.
• createSwapPayload now sorts the requested outputs by amount. It returns an additional keepVector (Array) that can be used to determine which outputs are meant to be kept. It also returns a sortedIndices array that can be used to reorder the sorted outputs in their original order.
• Removed some of the old blinding code. Was internal code, so no breaking changes.

PR Tasks

• Open PR
• run npm run test --> no failing unit tests
• run npm run format

[gudnuf]

Looks great! Just some minor nits and questions.

I don't fully understand the keepFactory and when it used. Can you elaborate a bit more on the logic behind that? My assumption is that this is used as a way to default how the user wants to store their proofs, but I think my confusion is related to my comment here

[gudnuf]

why are you using the keepFactory for send?

[Egge21M]

Good catch. Unfortunately there is a bug in the current version that requires this: #224

[Egge21M]

Looks great! Just some minor nits and questions.

I don't fully understand the keepFactory and when it used. Can you elaborate a bit more on the logic behind that? My assumption is that this is used as a way to default how the user wants to store their proofs, but I think my confusion is related to my comment here

Thank you for taking the time to go through this!
The idea of the keepFactory is to provide a standard "fallback" factory to the CashuWallet instance that should be used whenever we create proofs that are supposed to be "kept" (e.g. mint, melt-change, send-change, receive, etc.).

Using this, you can create a factory that creates some sort of outputs (like deterministic ones) and make the library use is automatically. A simplistic example of a CashuWallet that creates auto-incrementing, deterministic secrets using a keepFactory can be seen here: https://njump.me/nevent1qqsvzxrfqyt5xk0s7f60mm9rlthkdtv70g3qsl8xykrgcvnfdrfpaecpzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxgqg0waehxw309ahx7um5wghx6mmdqgsdmup6e2z6mcpeue6z6kl08he49hcen5xnrc3tnpvw0mdgtjemh0slwxw3x

[lollerfirst]

Can amt be zero?

[Egge21M]

Check out #240
I think this check was redundant. Removed the check in the refactor