Chain porter proof courier service initialised using configurable address

[ffranr]

This PR includes changes which allow us to persist a proof courier address for use in resuming a pending package's send process.

Fixes #446

[ffranr]

Having spoken with @guggero , I'm going to modify this PR as follows:

The goal is for the proof courier address to survive the chain porter send package log/resume cycle so that it is available when constructing the proof courier service handle.

To accomplish that, instead of adding the proof courier address as a new field in the asset transfer table, I will add a new addr field to vPSBT outputs and corresponding db table.

[guggero]

Just to clarify: my intention was to store the full, serialized tap-address in the vPSBT and transfer_output_table, not just the proof courier address. that way we get ourselves some future proofing if we ever add another attribute to a tap-address, then don't need yet another field in vPSBT/transfer-output.
I think that outweighs the downside of making the vPSBT slightly bigger with the somewhat duplicate info. Or do you strongly disagree on this, @Roasbeef?

[Roasbeef]

To accomplish that, instead of adding the proof courier address as a new field in the asset transfer table,

Or we just also store the full address as well which may be useful for record keeping purposes?

serialized tap-address in the vPSBT and transfer_output_table, not just the proof courier address. that way we get ourselves some future proofing if we ever add another attribute to a tap-address, then don't need yet another field in vPSBT/transfer-output.

Why's it need to be the vPBST vs just a new column in the row?

[ffranr]

Following a call with @Roasbeef , this is the latest direction for this PR:

Where the chain porter is concerned, we no longer add the Tap address to VPacket.VOutput. Instead, we now carry the addresses in sendPackage using a map from output index to Tap address. Then, we carry the proof courier address only in transfer output and it's SQL table.

This PR also includes changes to the custodian, which now instantiates a proof courier service using the address that we lookup in our address book.

This PR also changes the proof.Courier interface: proof.Courier[Addr any] -> proof.Courier. However, the recipient arg still remains in the DeliverProof and ReceiveProof methods. My idea there is that we might, in the future, want to connect to a service once and then reuse that service for multiple different recipient lookups. So I figured I wouldn't make a courier service handle specific to a recipient.

I think the following test breaks between 00:00 and 01:00 https://github.com/lightninglabs/taproot-assets/blob/fad3d845f68ec7fa09eb0c05f5f9c7455358928e/tapdb/universe_stats_test.go#L201C42-L201C42

This PR doesn't include a new RpcCourier, I'll add that in another PR. I would prefer not to extend this PR if possible.

This PR should now also close #462

[guggero]

Nice progress on this! Everything around the proof courier interfaces and delivery looks great. Though I don't think we can get away without storing the address in the vPSBT as well (see inline comment) for the full vPSBT interactive cases.

[guggero]

LGTM pending @Roasbeef's comments.

[Roasbeef]

LGTM 🏄🏾