We updated the create_multimedia_message endpoint to be able to handle payloads of type SendMultimediaMessageRequest:

export type SendMultimediaMessageRequest =
  | {
      +threadID: string,
      +localID: string,
      +mediaIDs: $ReadOnlyArray<string>,
    }
  | {
      +threadID: string,
      +localID: string,
      +mediaMessageContents: $ReadOnlyArray<MediaMessageServerDBContent>,
    };

The payload which contains mediaMessageContents is the "new" payload which enables us to create video messages. The MediaMessageServerDBContent object encodes the relationship between a media (photo or video) and corresponding upload(s). By passing that object to the keyserver, we're able to properly "reconstruct the media" in multimediaMessageCreationResponder(...).

This diff fully implements multimediaMessageCreationResponder(...) which is heavily influenced by the existing legacyMultimediaMessageCreationResponder(...).

The two main differences are:

1. We use the newly created fetchMediaFromMediaMessageContent(viewer, mediaMessageContents) instead of the legacy fetchMedia(viewer, mediaIDs) in order to be able to properly reconstruct media of type Video.
2. We use the newly created assignMessageContainerToMedia(viewer, mediaMessageContents, id) to assign the correct container to all uploads associated with the mediaMessage (including thumbnails).

Depends on D5087

Set breakpoints throughout multimediaMessageCreationResponder(...) and ensured that values were as expected at each point.
Checked uploads table of the serverDB to ensure that rows appeared as expected for each media message.