Under Taproot don't (always) use the max satisfaction weight for a script

[darosior]

To avoid introducing more complexity, #985 kept the size estimation of an input spending a coin sent to our descriptor to be the maximum possible between all spending paths. However under Taproot spending from different paths might make a huge difference and we may well be overestimating the size of the spending transaction (therefore overpaying the fees).

There is something we can do using Alekos' planning module in rust-miniscript as we have information about how a transaction may be spent at the time of creation due to how the nSequence is set. We could use the maximum satisfaction size between all spending paths available for instance.

But the low hanging fruit really is when the primary path is a single key which becomes the Taproot internal key. We could detect this case even without using the planning module.

[nondiremanuel]

The low hanging fruit part will be managed in a separate issue (#1118 )