polls: Read-only support

[gnprice]

As a first step of poll support (#164), we should render poll messages.

For product context, see https://zulip.com/help/create-a-poll .

For details of this part of the API… unfortunately this is one of the few remaining parts of the Zulip API that is effectively undocumented, and one has to resort to reverse-engineering. Two useful resources for reference are:

• The implementation in zulip-mobile, which comes from reverse-engineering and embodies notes about the format.
  • This lives mainly in src/webview/html/message.js, in particular widgetBody. (Here "widget" is a term this part of Zulip sometimes uses for an abstraction whose primary example is polls.)
  • See also types Submessage, SubmessageData, WidgetEventData, and WidgetData in src/api/modelTypes.js, and their jsdoc.
• The implementation in Zulip web.
  • Part of this is in JS code that's shared with zulip-mobile: see web/shared/src/poll_data.js and its neighbor poll_data.js.flow. This is used by the zulip-mobile implementation mentioned above.
  • The web-only code that consumes that poll_data module may also be informative.

[gnprice]

Ideally the information we show here would match what's in Zulip web: in particular for each option it'd show the number of votes and also the list of people who voted for it.

Currently zulip-mobile actually shows less than that:

• zulip/zulip-mobile#4882

I think it's probably just about as easy to go ahead and show that information, when we're working on this issue, as to not do so. In that case we should go ahead and show it.

(I think when we added poll support in zulip-mobile I may have been concerned that the list of voters would be too big to comfortably view in the message, the way web does it, on a mobile-size screen. A more mobile-optimized alternative would be to have the list on a separate screen, similar to the list of people who reacted on a message. But given that we never followed up by building that second screen and the interaction to get to it, it would have been better in retrospect to go ahead with the perhaps-unwieldy inline list of voters.)

[gnprice]

A small extra implementation note:

There are some ancient messages (2019-01 and earlier) on at least chat.zulip.org which use a different variation of the polls API, which was changed while the feature was still experimental before it was released. When we see such a message, we should just reject it without trying to parse it further.

Specifically that variation involves new_comment rather than new_option. Details at:

• https://github.com/zulip/zulip/issues/30148