The existing multimediaMessageCreationResponder accepts:

• threadID: string
• localID: string
• mediaIDs: string[]

This information is sufficient to create IMAGES messages (type 14), but not MULTIMEDIA messages (type 15). In order to properly represent the relationship between primary media and thumbnail media we need to replace the list of strings with a list of something like the following:

export type MediaMessageContent =
  | {
      +type: 'video',
      +mediaID: string,
      +thumbnailID: string,
    }
  | {
      +type: 'photo',
      +mediaID: string,
    };

We could change the create_multimedia_message endpoint to handle a $ReadOnlyArray<MediaMessageContent>... but that would break existing clients.

We could also create a seperate create_multimedia_message_v2 endpoint, but that would lead to a lot of branching (and changes that need to be made elsewhere eg endpoints.js).

The simplest/cleanest approach in my mind is:

1. Extract the existing functionality out of multimediaMessageCreationResponder into legacyMultimediaMessageCreationResponder (to support old clients).
2. Modify sendMultimediaMessageRequestInputValidator to optionally accept a list of MediaMessageContent
3. If a request includes mediaIDs, send it over to legacyMultimediaMessageCreationResponder
4. If a request includes mediaMessageContent, it'll be handled within multimediaMessageCreationResponder.
5. Implement multimediaMessageCreationResponder to handle MULTIMEDIA messages (will likely require some new queries, etc)
6. Modify native (message-actions: sendMultimediaMessage(...)) to hit the updated multimediaMessageCreationResponder endpoint with mediaMessageContent instead of mediaIDs.

7. Make sure that old clients continue to work with these changes.
8. etc...

In the long run (outside of the scope of our current video work), I think it makes sense for both photos and videos to use the more flexible MULTIMEDIA: 15 message type.

Depends on D4980

1. Send image message on native.
2. Send video message on native.
3. Set breakpoints in legacyMultimediaMessageCreationResponder and log key values to ensure that things continue to work as expected.