Sync meeting conversation name on title update

[thisisamir98]

Summary

• Add InternalRenameConversation to the conversation subsystem for server-side renames without a client connection id
• When a meeting title is updated via PUT /meetings, rename the linked MLS meeting conversation if its stored name differs
• Add a unit test asserting the returned MeetingWithConversation includes the updated conversation name

Context

Meeting creation already sets newConvName = Just newMeeting.title on the underlying conversation. Title updates previously only changed the meetings table, leaving cnvmName stale on the conversation. Web clients can rely on conversation metadata and rename events once this is deployed.

Test plan

• cabal test wire-subsystems:unit-tests --test-options='--match=MeetingsSubsystem.Interpreter'
• Update a meeting title and verify GET /conversations/:id returns the new name
• Verify conversation rename notifications are emitted to members

[supersven]

@thisisamir98 I'm not sure if you got access to our CI? 🤔

Just in case, it's failing with

wire-subsystems> src/Wire/MeetingsSubsystem/Interpreter.hs:337:21: error: [GHC-18872]
wire-subsystems>     • Couldn't match type ‘Text’ with ‘Range 1 256 Text’
wire-subsystems>         arising from selecting the field ‘cnvmName’
wire-subsystems>     • In the first argument of ‘(/=)’, namely ‘conv.metadata.cnvmName’
wire-subsystems>       In the expression: conv.metadata.cnvmName /= Just newTitle
wire-subsystems>       In a stmt of a pattern guard for
wire-subsystems>                      a case alternative:
wire-subsystems>         conv.metadata.cnvmName /= Just newTitle
wire-subsystems>     |
wire-subsystems> 337 |     Just newTitle | conv.metadata.cnvmName /= Just newTitle -> do
wire-subsystems>     |                     ^^^^^^^^^^^^^^^^^^^^^^
wire-subsystems> 
wire-subsystems> src/Wire/MeetingsSubsystem/Interpreter.hs:339:90: error: [GHC-83865]
wire-subsystems>     • Couldn't match expected type ‘Text’
wire-subsystems>                   with actual type ‘Range 1 256 Text’
wire-subsystems>     • In the first argument of ‘ConversationRename’, namely ‘newTitle’
wire-subsystems>       In the third argument of ‘ConversationSubsystem.internalRenameConversation’, namely
wire-subsystems>         ‘(ConversationRename newTitle)’
wire-subsystems>       In a stmt of a 'do' block:
wire-subsystems>         ConversationSubsystem.internalRenameConversation
wire-subsystems>           zUser lConvId (ConversationRename newTitle)
wire-subsystems>     |
wire-subsystems> 339 |       ConversationSubsystem.internalRenameConversation zUser lConvId (ConversationRename newTitle)
wire-subsystems>     |                                                                                          ^^^^^^^^
wire-subsystems> 

[blackheaven]

IMO, we should be more subtle than this, there are multiple scenarii:

• A new meeting creates a new conversation
• A new meeting links to an existing conversation which has none
• A new meeting links to an existing conversation which has some

Which leads to few options:

• It's handled in the frontend (via a checkbox, or using Meeting.title as a source of truth)
• We add logic to the backend to update it when we have 1 meeting = 1 conversation
• We add a parameter to the endpoint

@akshaymankar WDYT?

[akshaymankar]

@thisisamir98 What's the context for this? Why can't the clients just show meeting title? Since the group_conv_type will be meeting, I believe the clients can do this on their own?