Set LAST_MESSAGE_ANCHOR to 10000000000000000 (sixteen zeroes).

[chrisbobbe]

Fixes: #3654.

The server correctly interprets this special number as indicating
that we want the latest messages (0 is used to request the oldest
messages). Later, we can conditionalize on the server version to
support the updated API merged in
zulip/zulip#13747, that use the strings
'oldest' and 'newest' instead of 0 and 10000000000000000.

[gnprice]

Thanks @chrisbobbe !

One point in the commit message: in the API, 0 doesn't mean the oldest unread messages, but simply the oldest. The legacy API for "oldest unread" is a separate boolean flag use_first_unread_anchor: true, which causes anchor to be ignored.

... Looking closer through our code for this, now that I have those facts about the API in my head from reading zulip/zulip#13747 recently, I see that within our code we do it the way the commit message describes, though. (And I guess we never make a request for simply the oldest messages.) It's confusing that we do something that's so almost, but not quite, like the server's API. I may see if there's a quick refactor I can do to clean that up.

Anyway, I'll make that adjustment in the commit message and then merge.

[gnprice]

And pushed 7a3a845 to try to clean up that confusion a bit:

commit 7a3a845477127fdb7a10b2dd682650c06f93ebaf
Author: Greg Price <[email protected]>
Date:   Thu Feb 6 20:45:28 2020 -0800

    anchor [nfc]: Correct the jsdoc on FIRST_UNREAD_ANCHOR.
    
    This jsdoc didn't match the name at all!  It turns out the name was
    right... and the jsdoc described what, confusingly, the very same
    value means in the actual Zulip API.

I also explored a refactor to actually stop using 0 in this confusing way. I have a draft that more or less does it, but more work is required before that's mergeable.