Optimistically store message in libxmtp DB on message send

[richardhuaaa]

On message send, libxmtp does a sophisticated publishing flow that may take multiple network round trips to resolve. Integrators should be able to optimistically render that message in their UI before the send has been confirmed to be published. To enable that, we can write the message to our database as soon as the send is requested, with a "state" field of UNPUBLISHED, and update it after publishing to PUBLISHED. That way, integrators can just query the messages, and decide whether or not they want to render the UNPUBLISHED messages.

The message ID currently depends on a server timestamp, and therefore can only be determined once the message is published. In order to optimistically write the message to the database, we need to modify how the message ID is determined, and use a client timestamp instead. The client timestamp is not included on the message payload anywhere, so others won't be able to determine the message ID until we add it onto the payload.

1. Write an envelope proto for the encrypted MLS payload that wraps encoded content. Add a field to the envelope called ‘sender_idempotency_key’ or similar.
2. (Breaking change) Run dev/gen_protos.sh in libxmtp and implement the proto (serialization on message send and deserialization on message receive), including setting the new field on message send to the sender's client timestamp. Once landed, notify everyone that it is a breaking change.
3. Update how message_id is generated to use the new field - previously used the group_id, hash of the decrypted message contents, and the server timestamp - now we can replace the server timestamp with (sender_account_address, sender_client_timestamp). Add “state” field to group_messages table (default it to PUBLISHED in the SQL migration, but make it a required field in the code going forward). Insert an optimistic row on message send with state UNPUBLISHED, and update it to PUBLISHED after commit publishing flow.

Other thoughts:

• The send() function won't return for integrators until the full publish flow is complete. In future, we could consider having it return early and do the rest in a background thread. Not sure if this matters or not/how multi-threaded integrators are already.
• The sent message won't be returned via message streams until it is published and then read back from the server. Unsure if this matters or not.
• Integrators can't subscribe to changes on message state. I assume this is too sophisticated for now, and they could also determine that the state has transitioned to PUBLISHED once they read it back from the stream.

[neekolas]

I have a PR up for the envelope (not sure about the naming, open to suggestions).

I also added some ideas of where we should use this, and where we should store the two fields separately. Feel free to weigh in here on usage. Think we want to get that clear so that we don't have callers expecting one thing and getting another.

[insipx]

This should be fixed, rel. #881 #544