Adding support for lightning addresses within contacts

[robbiehanson]

This PR adds support for lightning addresses within the Contacts functionality.

For existing contacts, the UI looks nearly identical:

But it now allows for multiple offers to be added, and multiple lightning addresses too:

When you add/edit an offer, you're now able to (optionally) provide a label:

This is quite helpful because, if a user does have multiple offers, they're probably for different wallets, or different services (in the case of a business). So the label is quite necessary.

Tapping the 3-line button provides a menu with various options:

---

Technical notes:

• There's a new database table called contact_addresses, which basically uses the same layout as the existing contact_offers.

• When you fetch a ContactInfo, it now looks like this:

data class ContactInfo(
    // ...
    val offers: List<ContactOffer>,
    val addresses: List<ContactAddress>
)
data class ContactOffer(
    val id: ByteVector32,
    val offer: OfferTypes.Offer,
    val label: String?,
    val createdAt: Instant
)
// ...

• ContactsManager has been simplified. That is, there used to be various functions like these:

suspend fun saveNewContact() { /* ... */}
suspend fun updateContact() { /* ... */}
suspend fun detachOfferFromContact() { /* ... */}

These functions are gone, and in their place is a single function that does everything for you:

/**
 * This method will:
 * - insert or update the contact in the database (depending on whether it already exists)
 * - insert any new offers
 * - update any offers that have been changed (i.e. label changed)
 * - delete offers that have been removed from the list
 * - insert any new addresses
 * - update any addresses that have been changed (i.e. label changed)
 * - delete any addresses that have been removed
 *
 * In other words, the UI doesn't have to track which changes have been made.
 * It can simply call this method, and the database will be properly updated.
 */
suspend fun saveContact(contact: ContactInfo) { /* ... */}

Note that even though this function is helpful, the UI cannot call it blindly. We don't support duplicate offers within the system. That is, you can't add offer X to contact Bob if offer X is already associated with contact Alice. Attempting to do so will throw a sqlite error. And the same restriction applies to duplicated addresses. So the UI is responsible for checking, and displaying the proper error message to the user.

• Since the ContactsManager already keeps all contacts in memory (via contactsList: StateFlow<List<ContactInfo>>), there are a bunch of (non-suspending) functions to fetch the ContactInfo given a:
  • payment
  • offerId
  • offer
  • publicKey
  • address

This means you can replace the call to suspend fun getContactForOffer(offer: OfferTypes.Offer) with fun contactForOffer(offer: OfferTypes.Offer)

---

Todo:

• If the user pastes an offer in the Send screen, we have a "Add to contacts" option. The same is not true for pasting/typing a lightning address.
• The "Add to contacts" should also allow the offer/address to be added to an existing contact.
• After sending a payment to an offer, and later viewing the sent payment, there should be a "add to contacts" option within the UI
• After sending a payment to an address, and later viewing the sent payment, there should be a "add to contacts" option within the UI

---

Motivation:

Not a lot of wallets support Bolt12 offers yet. Even less support receiving a payment via their own offer. Which means our Contacts functionality is basically limited to just Phoenix users right now.

Additionally, many people will simply prefer lightning addresses. They're a familiar format. And they're human-readable, and human-writable, and human-speakable. And they're modifiable (i.e. If I own/control the address, I can point it at a new wallet. Which gives me wallet independence.)

So this is a nice increase in the functionality of our Contacts feature.