This is just a simple rename.
Why are we doing this?
We've modified multimediaMessageCreationResponder in the last diff (D5058) to accept a t.list(tMediaMessageMedia) while continuing to support t.list(t.String) (via legacyMultimediaMessageCreationResponder).
We needed to make this change so the client could communicate to the keyserver the relationship between each piece of media (photo or video) and corresponding uploads for video messages.
We want to update native to use the updated payload when hitting the create_multimedia_message endpoint. However, we don't want to break web while we're doing that.
So, we're keeping the existing sendMultimediaMessage around and renaming to legacy... so everything continues to work. Then
- Introducing a new version of sendMultimediaMessage to be consumed by native that sends over the new payload
- Implementing "new" multimediaMessageCreationResponder to handle the new payload
3-?: Making whatever changes on native needed to get video messages working end-to-end
?+1: Updating input-state-container on web to use the new sendMultimediaMessage
?+2: Removing legacySendMultimediaMessage altogether
Basically this lets us defer updating input-state-container on web while we're figuring things out on native.
Depends on D5058