graph/db: extract InboundFee at deserialisation time

Here we add an explicit InboundFee field to the ChannelEdgePolicy
struct. Then, in the graph KVStore, at deserialisation time, we extract
the InboundFee from the ExtraOpaqueData. Currently we do this at higher
levels but we are going to move it to the DB layer so that when we add
the SQL implementation of the graph store, we can have explicit columns
for inbound fees. We need to account for the fact that we may have
invalid TLV already persisted though and we dont want to fail if we
deserialise those necessarily. So we return ErrParsingExtraTLVBytes now
if we fail to parse the extra bytes as TLV and then we let the callers
handle it similarly to how ErrParsingExtraTLVBytes is handled in that we
dont necessarily fail if we receive one of these errors.

As of this commit, we can now expect the InboundFee field of a
ChannelEdgePolicy to be set (if inbound fees are set on the policy) for
any update that we read from disk.

graph/db/models/channel_edge_policy.go

@@ -5,6 +5,7 @@ import (
 	"time"
 
 	"github.com/btcsuite/btcd/btcec/v2/ecdsa"
+	"github.com/lightningnetwork/lnd/fn/v2"
 	"github.com/lightningnetwork/lnd/lnwire"
 )
 
@@ -65,6 +66,15 @@ type ChannelEdgePolicy struct {
 	// to. Using this pub key, the channel graph can further be traversed.
 	ToNode [33]byte
 
+	// InboundFee is the fee that must be paid for incoming HTLCs.
+	//
+	// NOTE: for our kvdb implementation of the graph store, inbound fees
+	// are still only persisted as part of extra opaque data and so this
+	// field is not explicitly stored but is rather populated from the
+	// ExtraOpaqueData field on deserialization. For our SQL implementation,
+	// this field will be explicitly persisted in the database.
+	InboundFee fn.Option[lnwire.Fee]
+
 	// ExtraOpaqueData is the set of data that was appended to this
 	// message, some of which we may not actually know how to iterate or
 	// parse. By holding onto this data, we ensure that we're able to