JS Client: add support for Taproot inputs

[fess-v]

There's code in the psbtv2.ts file which throws an error when taproot inputs are passed using BitcoinJS lib PSBT, as it was implemented in this PR

if (isTaprootInput(input))
        throw new Error(`Taproot inputs not supported`);

Could it be implemented to allow taproot inputs to be passed in this case? Is there anything blocking from doing so?
P.S.
I use it with a tapleaf script spending path, not an internal public key. I'm also trying to make the correct version of a custom WalletPolicy for that scenario. Should I use multi_a for the descriptor in this case? If it's a multisig N of M, where order is not important.
So I also wonder if it would be possible to use leaf scripts with PsbtV2 and if there's already ongoing work on that.
Thanks!

[bigspider]

From the last version, the JS module accepts a psbt as either a base64-encoded string, or a binary Buffer; that's now the recommended way, as it allows you to use whichever external Psbt class you prefer, and serialize it before calling the ledger client. The Psbtv2 class is at this point deprecated and will probably be removed in a future version.
Note that while the app internally uses Psbt version 2, you can pass a serialized psbt V0, and the conversion will be handled automatically in the client.

Wallet policies support (limited) taproot scripts from the last version (2.1.3) of the app, but leaves can only be pk(), multi_a() or sortedmulti_a(). Order is important in multi_a, while it's irrelevant in sortemulti_a (although, in practice I don't think it makes a difference, as you will have to backup the descriptor anyway).

[fess-v]

@bigspider thanks a lot for your reply! looked before into the code of the frontend library and it has:

if (typeof psbt === 'string') {
      psbt = Buffer.from(psbt, "base64");
    }

    if (Buffer.isBuffer(psbt)) {
      const psbtObj = new PsbtV2()
      psbtObj.deserialize(psbt);
      psbt = psbtObj;
    }

So thought it works with PsbtV2 in all cases equally, but seems to be working fine as a base64 string.
Seems like the main issue on our side is the inability to pass public keys to wallet policies, described in this issue
But I see the point about normal public keys being less private and it makes sense, although it restricts us from integrating ledger to our multisig at this point.

[bigspider]

Thanks for your comments on the other issue - closing this one.