Multi rfq send itest

[GeorgeTsagk]

Description

Enhances the multi-rfq itest to cover multi-rfq send functionality. In the following topology

	  /---[sats]--> Erin --[assets]--\
	 /                                \
	/                                  \

 Charlie  -----[sats]-->  Dave  --[assets]---->Fabia

	\                                  /
	 \                                /
	  \---[sats]--> Yara --[assets]--/

we now also get Fabia to pay Charlie back, with amounts that exceed the capacity of each individual channel. We also use a hold invoice to validate that multiple HTLCs were added in different channels.

Related PRs (in order of merge sequence):

• AuxTrafficShaper methods use first hop pub key lightningnetwork/lnd#9980
• Add Multi-RFQ Send taproot-assets#1613
• (temp)build: bump lnd & tapd loop#968

[ZZiigguurraatt]

Seems like you should update

https://github.com/GeorgeTsagk/lightning-terminal/blob/c7dbe80f1b6463bb01fe2f94f72cf52b6b6ab9de/itest/litd_custom_channels_test.go#L2973-L2977

to mention the send test, possibly renaming the function name?

[ZZiigguurraatt]

In the following topology

	  /---[sats]--> Erin --[assets]--\
	 /                                \
	/                                  \

 Charlie  -----[sats]-->  Dave  --[assets]---->Fabia

	\                                  /
	 \                                /
	  \---[sats]--> Yara --[assets]--/

Do we see any value in adding tests where Charlie has more or less channels than Fabia? Like this route seems a bit too simple because both sender and receiver kind of need the same sharding.

I'm also wondering if we should test where Charlie-Dave have asset channels and not sats channels.

I don't think this test should be removed, but I think there should be some more complex network that tests more than what this test can do in another function.

[GeorgeTsagk]

Linter / unit tests fail because of this
https://github.com/lightninglabs/lightning-terminal/actions/runs/16022889778/job/45203816341?pr=1097#step:5:317

accounts/sql_migration_test.go:340:19: undefined: sqldb.MigrationTxOptions (typecheck)

which is not related to this PR, the itests should normally run & pass

[GeorgeTsagk]

The last commit adds a new node to the topology, which always rejects quotes, causing a reliable RFQ negotiation failure this way

The tests pass, but they do now expose some potential bug in the RFQ negotiation code where we hang until timeout if the rfq negotiation is not successful.

[guggero]

LGTM pending a couple of nits.

[lightninglabs-deploy]

@ffranr: review reminder
@GeorgeTsagk, remember to re-request review from reviewers when ready

[ffranr]

Need to remove the replace in go.mod, and some other outstanding comments, otherwise good to go.

[ZZiigguurraatt]

Need to remove the replace in go.mod, and some other outstanding comments, otherwise good to go.

FYI: I made a branch where I rebased and then updated all the packages. Not sure if you want to use it or re-do it another way.

https://github.com/ZZiigguurraatt/taproot-assets/tree/group-key-addr-part-2%2Bmulti-rfq-send

[ZZiigguurraatt]

Need to remove the replace in go.mod, and some other outstanding comments, otherwise good to go.

FYI: I made a branch where I rebased and then updated all the packages. Not sure if you want to use it or re-do it another way.

https://github.com/ZZiigguurraatt/taproot-assets/tree/group-key-addr-part-2%2Bmulti-rfq-send

sorry, got this PR mixed up with the other one.

[guggero]

@GeorgeTsagk can you please rebase this to the tapd-main-branch branch? We can't bump tapd on master branch yet, as we're not ready to release what will become tapd v0.7.0 yet (in case we need to do an emergency minor release of litd).

[ZZiigguurraatt]

@GeorgeTsagk can you please rebase this to the tapd-main-branch branch? We can't bump tapd on master branch yet, as we're not ready to release what will become tapd v0.7.0 yet (in case we need to do an emergency minor release of litd).

do we want to prio lightninglabs/loop#968 now so that this can be done more cleanly?

[GeorgeTsagk]

Rebased on tapd-main-branch

[GeorgeTsagk]

do we want to prio lightninglabs/loop#968 now so that this can be done more cleanly?

We can't merge the loop PR until the tapd PR gets merged, as we have to provide the final go mod ref