Use last_moved_timestamp instead of scanning edit_history

[gnprice]

The server will be introducing (probably in Zulip Server 10) a field last_moved_timestamp on message objects, as well as narrowing the meaning of last_edit_timestamp. Together these are intended to let the client skip scanning through edit_history to determine whether a message has been edited or moved.

We should start interpreting the new fields when present, instead of doing that scanning. This will be more efficient, and also a step toward the server being able to stop sending the full edit history in the future.

Implementation

On old servers, we'll continue scanning edit_history. Let's have that logic express its conclusion in the form of the same last_moved_timestamp and last_edit_timestamp information that new servers send.

Then the rest of the app can effectively use the new API, looking at those two fields, without caring about the existence of the old API.

References

• #api design > edit history @ 💬
• Server/web PR: message_edit: Add last_moved_timestamp. zulip#33872