Adds conversation_type to MlsGroup struct in favor of reading group metadata state for conversation_type

[cameronvoell]

See iOS repro test PR this was tested against for performance:

xmtp/xmtp-ios#542

got this three times in a row on my repro before this libxmtp update:

syncAllConversations() ▸ 65.385 s for 1201 convos

=== TIMING STATISTICS ===
conversations.list() ▸ avg: 1.465s, max: 50.721s (43 calls)
messages() ▸ avg: 0.002s, max: 0.005s (43 calls)
findConversation() ▸ avg: 0.001s, max: 0.003s (43 calls)
updateConsent() ▸ avg: 0.000s, max: 0.001s (43 calls)
=== END ===

and then after libxmtp update conversations.list() never hit the high max again:

conversations.list() ▸ avg: 0.017s, max: 0.039s (1698 calls)
messages() ▸ avg: 0.001s, max: 0.013s (1698 calls)
findConversation() ▸ avg: 0.000s, max: 0.006s (1698 calls)
updateConsent() ▸ avg: 0.000s, max: 0.006s (1698 calls)

Store conversation type as field in MlsGroup struct instead of retrieving from group state metadata

The MlsGroup struct now stores conversation_type as a direct field rather than retrieving it asynchronously from metadata. The conversation_type() method changes from an async method that queries metadata to a synchronous method that returns the stored field. All MlsGroup creation methods across the codebase are updated to accept and pass the conversation_type parameter. The FfiConversation.conversation_type() method in bindings_ffi/src/mls.rs becomes synchronous and directly returns the stored value. A new get_conversation_type() method is added to the QueryGroup trait in xmtp_db/src/encrypted_store/group.rs to retrieve conversation types directly from the database.

📍Where to Start

Start with the MlsGroup struct definition and its conversation_type() method in xmtp_mls/src/groups/mod.rs to understand how the conversation type field is now stored and accessed.

Changes since #2249 opened

• Added conversation_type parameter to MlsGroup constructor call [0c65c4a]
• Changed conversation type parameter in MlsGroup initialization during message recovery [ee2d364]

---

Macroscope summarized ee2d364.

[cameronvoell]

• Adds conversation_type to MlsGroup struct in favor of reading group metadata state for conversation_type #2249 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[cameronvoell]

This is the one place the new conversation type needs to be added where we dont know its value. I think we're also populating dummy data for dm id here and the code path looks like conversation_type is not used, so I think this is safe for now, but seems like a code smell.