Audit enums in API to parse laxly where appropriate

[gnprice]

This is a followup to:

• Accept unknown "emojiset" values #1981

For many of the enums in the Zulip server API, we gracefully handle the possibility that the server sends some value we didn't expect (presumably reflecting some future API change). This means that when parsing the server response, we record the value as some kind of "unknown" value, and then the code inside the app that ends up consuming the value does something appropriate when it sees such a value.

There are a few places in the API where the enum is so fundamental to how to proceed that it wouldn't make sense to try to interpret the rest of the data: a good example is the type field on a message (https://zulip.com/api/get-messages#response ), where if there's some future kind of message that's neither a channel message (type: "stream") nor a direct message (type: "private"), then it's impossible to predict today what would be reasonable for a client to do with such a message. In those places, if we see an unknown enum value then we just reject the server's whole response as malformed.

But those should be rare. We saw in #1981 a case where we were/are rejecting unknown values as malformed when we really shouldn't — when there's a perfectly reasonable fallback behavior we can apply instead.

There might be more such cases. (The code is easier to write that way; plus in the early period of this new app, we hadn't yet worked out a good pattern for gracefully handling unknown values. The code in #1981 dates from that period.) So we should audit all the enums that appear in our types describing server responses in the API, and find and fix any remaining such cases.

Implementation

The key here is to look at each enum in lib/api/, and each of the places those enums appear in parsing server responses.

For many of those, we're already gracefully handling unknown values.

For others, we might fix them to do so, similar to #1981.

Then for every remaining place where we continue to reject unknown values, we should have a clear story for why that's appropriate.

Plus, even for those, we should consider if there are some values that we might predictably update the API to have the server start sending in the future. For example, the message type field mentioned above — currently it's stream or private, which are old names for those concepts, and it'd be nice to someday update those to channel and direct (as the server already accepts for the corresponding field at https://zulip.com/api/send-message , because that change only expands what the server accepts and so could be made with no compatibility obstacle), so we might as well have the app accept those values too with their predictable meanings.

[gnprice]

This issue is one that will not be suitable for a contributor who's new to Zulip. A key element of resolving this issue will be to clearly explain why each enum either should or shouldn't accept unknown values, and what the app should do with unknown values if it does accept them.