Consider splitting /changes#changed response into "created" and "updated"

[neilj]

Pending conclusion on mailing list discussion.

I see the following advantages:

• The client receives more information, so has more flexibility to implement strategies such as always fetching new messages in the same request but delaying fetching updates until the next round trip (and thus can omit fetching these at all if it has a partial cache and the changes are for messages it doesn't have cached anyway).
• It mirrors the /set create, update, destroy distinction, which I think makes it more consistent and easier to understand.
• Some APIs like Core Data are more efficient if you don't have to check whether you already know about an id to decide whether it's a create or update
• You can use this to easily check for ids you care about for notifications (new message deliveries), and ignore those that are just changed.

and disadvantages:

• The server must store more state in order to calculate this; for example, if using a modseq system, it now needs to store a created modseq as well as a modified modseq.
• You need two Email/get back-references if you want to fetch both updates and new messages in the single request. This could be less efficient for the server to process and adds syntax overhead in both directions. The server could certainly make this pretty much as efficient to process by detecting successive /get calls and processing them together (so it keeps caches open rather than closing between method calls etc.), but this does add complexity.