Make use of caching headers on server emoji data

[gnprice]

The Zulip server supplies to the client a list of all the Unicode emoji it understands. It does so in a way that's different from how most of the API works: instead of including the data in the registerQueue response, that response has just a URL, and the client then fetches from that URL separately. See server_emoji_data_url at https://zulip.com/api/register-queue .

The motivation for this is so that the data can be cached instead of fetched every time. The list changes infrequently — only on server upgrades, perhaps one such upgrade a year — so caching can be helpful. The URL contains a hash of the contents, and the server includes a broad cache-control HTTP response header, like:

$ curl -v https://chat.zulip.org/static/generated/emoji/emoji_api.ed3d6cb1ae06.json >/dev/null
[…]
< cache-control: public, max-age=31536000, immutable

Our initial implementation of #669 won't take advantage of that header, though — it'll just make the request after every registerQueue request, even if the URL is the same as it was last time. I think that's basically fine, so we'll leave fixing that as something for post-launch.

Details

Using the caching headers seems nontrivial to do: my current draft implementation, which just uses the Dart standard library's HTTP implementation in the same way we've done for other HTTP requests, doesn't empirically seem to do it. And I'm not finding any mention of caching-related options, or documentation of any caching behavior, in the docs:
https://pub.dev/documentation/http/1.2.2/http/Client-class.html
https://api.dart.dev/stable/3.5.3/dart-io/HttpClient-class.html

Conversely, just making the extra request each time isn't a major problem. Looking at server logs of my requests on chat.zulip.org,

• the registerQueue requests took the server around 4 seconds and returned about 2.8 MB of data;
• and then the emoji requests took the server 0.000 seconds and returned about 0.023 MB of data.

So the cost is negligible for the server, and for the client on a good network connection. On a high-latency connection, the extra request might mean a delay of a round-trip or two, so perhaps up to a second. But in any case we're not waiting for the response before showing the app's UI — the only impact of latency is that if you try to do something like leave an emoji reaction, we'll be working there from a lack of data.

Implementation

It might be possible to get Dart's HTTP client to handle these headers, with more digging.

Or this might be something we get as part of switching to a different implementation, like Cronet (package:cronet_http) on Android. That also came up at: #461 (comment)