[tapsend]: don't broadcast transaction until asset witness is valid (if time locked)

[guggero]

Discovered in #1287 (reply in thread).

When an asset is time locked (but the BTC anchor transaction is not), we currently publish a transfer transaction in the normal tapfreighter send flow, even if the asset would become invalid and factually burned because its time lock hasn't expired yet.

We need to add a check in the send flow that makes sure every asset's witness is valid with the current block height before publishing the transaction.

[gijswijs]

Isn't that what AssertAnchorTimeLocks is for?

https://github.com/lightninglabs/taproot-assets-private/blob/d696942ed97beec02ccc6bfcd9a833689ba8b044/tapsend/send.go#L1353

[guggero]

Isn't that what AssertAnchorTimeLocks is for?

https://github.com/lightninglabs/taproot-assets-private/blob/d696942ed97beec02ccc6bfcd9a833689ba8b044/tapsend/send.go#L1353

Yes and no. Bubbling up the time locks from the asset level to the anchor transaction level assumes that the BTC anchor transaction has the same time lock restrictions (which IMO in most cases makes sense, mostly to just prevent this case).
But if the BTC level is unencumbered by scripts (just normal keyspend path), then currently nothing stops the transaction from going through and effectively burning the assets in the process (because a proof will be generated that can never become valid).

Thinking about it a bit more, there would also be interactions with potential re-orgs. Time locks and re-orgs aren't a problem on BTC in general because when a re-org happens, the transactions just go back into the mempool. And if a time lock witness isn't valid anymore because of the re-org, the transaction would just be rejected and would need to be re-broadcasted at a later time.
But if an asset has a time lock restriction, the BTC level mempool mechanism wouldn't detect that and might include such a transaction in a block that's too early.

So perhaps we should make it very clear that for safety reasons the BTC level transaction should always have the same time lock in place?