rfqmsg: add noop option to HTLC

We add a new noop flag to the HTLC which, when set, will produce the
corresponding TLV record. We also hide this feature behind the dev flag,
as we ultimately want to be backwards compatible via some feature bit
related peer messages.

Author: GeorgeTsagk

rfqmsg/noop_add_active.go

@@ -0,0 +1,8 @@
+//go:build dev
+
+package rfqmsg
+
+// SetNoopAdd flags the HTLC as a noop_add.
+func (h *Htlc) SetNoopAdd() {
+	h.NoopAdd = true
+}

rfqmsg/noop_add_inactive.go

@@ -0,0 +1,6 @@
+//go:build !dev
+
+package rfqmsg
+
+// SetNoopAdd flags the HTLC as a noop_add.
+func (h *Htlc) SetNoopAdd() {}

rfqmsg/records.go

@@ -12,6 +12,7 @@ import (
 	"github.com/lightninglabs/taproot-assets/asset"
 	"github.com/lightninglabs/taproot-assets/fn"
 	"github.com/lightninglabs/taproot-assets/rfqmath"
+	"github.com/lightningnetwork/lnd/lnwallet"
 	"github.com/lightningnetwork/lnd/lnwire"
 	"github.com/lightningnetwork/lnd/tlv"
 )
@@ -59,6 +60,13 @@ type Htlc struct {
 
 	// RfqID is the RFQ ID that corresponds to the HTLC.
 	RfqID tlv.OptionalRecordT[HtlcRfqIDType, ID]
+
+	// NoopAdd is a flag that indicates whether this HTLC should be marked
+	// as a noop_add for LND. A noop_add HTLC behaves identically to a
+	// normal HTLC except for the settlement step, where the satoshi amount
+	// is returned back to the sender, but the commitment blob is still
+	// updated to reflect the asset balance changes.
+	NoopAdd bool
 }
 
 // NewHtlc creates a new Htlc record with the given funded assets.
@@ -135,6 +143,11 @@ func (h *Htlc) Records() []tlv.Record {
 		records = append(records, r.Record())
 	})
 
+	if h.NoopAdd {
+		r := tlv.NewPrimitiveRecord[lnwallet.NoopAddHtlcType](true)
+		records = append(records, r.Record())
+	}
+
 	return records
 }