tapchannel: enforce strict forwarding for asset invoices

[GeorgeTsagk]

This PR adds a few extra steps to the AuxInvoiceManager before it settles an invoice. Previously we wouldn't check that we received an asset HTLC for an asset invoice, leading to some undesired behavior.

With these changes we enforce that if the invoice corresponds to an asset invoice then we only settle it if we received assets.

Todo:

• Tests

Closes #1008

[coveralls]

Pull Request Test Coverage Report for Build 11385013038

Details

• 31 of 47 (65.96%) changed or added relevant lines in 2 files are covered.
• 23 unchanged lines in 5 files lost coverage.
• Overall coverage increased (+0.3%) to 40.663%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
rfq/manager.go	0	4	0.0%
tapchannel/aux_invoice_manager.go	31	43	72.09%

Files with Coverage Reduction	New Missed Lines	%
tapchannel/aux_leaf_signer.go	2	36.29%
asset/asset.go	2	81.8%
tapgarden/caretaker.go	4	68.87%
commitment/tap.go	5	83.64%
universe/interface.go	10	51.12%

Totals
Change from base Build 11293509981:	0.3%
Covered Lines:	24450
Relevant Lines:	60128

---

💛 - Coveralls

[dstadulis]

Before assigning reviewers, tests will need to be added.

[guggero]

Nice approach! And great to have a unit test. Though I wonder what would actually happen on the sender and receiver side with this change? My assumption is that things would just time out (rather than rejecting the HTLC).
So I think we should also have an integration test for this.

[guggero]

I wonder: Shouldn't an invoice always relate to a buy order only? Even in a direct peer payment, when I create an invoice, there should be a buy quote for it.

[guggero]

Hmm, interesting approach. What does actually happen with this though? Did you try this in an itest?
I'm assuming the payment will just time out if it's MPP (since the sender is waiting for settle and the receiver is waiting for more shards that pay toward the invoice since none of them actually held any value yet).
Or does the zero amount here lead to a direct error that is propagated back to the sender?

[GeorgeTsagk]

We're intercepting the invoice at the htlc level, which means that for mpp payments we'll intercept N times for N shards. Within the context of intercepting a single htlc we can only signal what the effective value of that single htlc is (i.e we can only ignore the "value contribution")

In the payment context we'll see a timeout, as we're still waiting for other htlcs that may sum up to the expected value

[GeorgeTsagk]

An itest that covers this behavior has been added in a litd PR