boltz: Validate initial claim destination address

[s373nZ]

Tries to prevent the following error in the logs:

Unhandled exception in concurrent task!
lightningd[181525]: Bitcoin::UnknownAddrType

In my case, the database table BoltzServiceFactory_rsub has four entries, all of which contain empty strings for the destinationAddress field. These blank fields are predictably un-parsable as Bitcoin addresses.

Without the validation, the empty addresses get passed in to building an initial claim tx here and an error is thrown here.

I have next to 0 experience with clboss code and am no C++ expert by any means. Submitting this as a PoC / draft PR for a quick glance and if it's on the right track, I'll attempt to finish the address parsing validation.

[s373nZ]

After a bit more research on the code and my DB state, I see there is a more robust system around clboss creating the swaps. Particularly, I've been trying to understand more about the SwapManager. To note, and possibly related to this issue are the facts that:

• SELECT * FROM SwapManager; return one row, with state=2 (enum AwaitingResult), but has no value initialized for the address column.
• SELECT * FROM SwapManager_addrcache; returns a total count of 95 rows, all except one have no values for the address field.

So... perhaps there is also an issue with address generation prior to the validation crash, as well.

[s373nZ]

Changed the query to exclude loading empty addresses from the address cache. An additional idea might be to run a quick SQL query to clean up the address cache on plugin startup by deleting records with empty address fields.

Need to revisit whether the initial validation changes are still appropriate.

[s373nZ]

Added an additional sanity check to not insert blank addresses from failed swaps into the address cache.

[s373nZ]

Also added an SQL query run when the SwapManager is initialized which would remove any erroneously created records in the address cache which contain blank addresses.

Haven't tested this PR yet, as I only have a prod node right now, but taking this PR out of draft to solicit initial feedback.

[ksedgwic]

Chris Guida recommends checking whether CLBOSS needs any P2TR support.

[chrisguida]

@ksedgwic I don't think that's the cause here as clboss is calling newaddr without params (which returns bc1q by default) and explicitly selects the bech32 key from the result.

But yes, generally it it probably good for us to make sure clboss is cool with taproot addresses.