previously, when adding items either at the beginnig (e.g. new notes
coming in while we're not looking at the top of the timeline) or a the
end (e.g. more items arriving from a background fetch) of a paginated
view, the resulting list got truncated to `displayLimit`, potentially
throwing data away and causing a new fetch.

This, coupled with the async nature of scrolling & fetching, could
cause weird results.

Also, `offset` was always incremented by the size of the fetched
results, even if not all of them were displayed, meant that it was
possible for offset-based pagination to drop items.

Finally, the "queue" of new items (usually, new notes) also got
truncated to `displayLimit`, which again could drop items (this effect
was usually masked by the first point: when scrolling to the top of
the timeline, if the queue's length was equal to `displayLimit`, those
notes displaced any existing ones, `unshiftItems` set
`more.value=true`, you got scrolled to the top, and notes were fetched
again, so you lost your position but at least all notes got shown,
eventually)

View MR for information: !488



Closes #487

Approved-by: Marie <marie@kaifa.ch>
Approved-by: Amelia Yukii <amelia.yukii@shourai.de>

View MR for information: !475



Closes #464

Approved-by: Marie <marie@kaifa.ch>
Approved-by: Luna <her@mint.lgbt>
Approved-by: Amelia Yukii <amelia.yukii@shourai.de>

View MR for information: !486



Approved-by: Marie <marie@kaifa.ch>
Approved-by: Amelia Yukii <amelia.yukii@shourai.de>

View MR for information: !490



Closes #494

Approved-by: Amelia Yukii <amelia.yukii@shourai.de>
Approved-by: Marie <marie@kaifa.ch>

without this, remote files are assumed to have size 0 (even if we just
downloaded them!) and the range-related code won't run

View MR for information: !487



Approved-by: dakkar <dakkar@thenautilus.net>
Approved-by: Marie <marie@kaifa.ch>

View MR for information: !469



Approved-by: dakkar <dakkar@thenautilus.net>
Approved-by: Marie <marie@kaifa.ch>

View MR for information: !481



Closes #483

Approved-by: Amelia Yukii <amelia.yukii@shourai.de>
Approved-by: Marie <marie@kaifa.ch>

View MR for information: !485



Approved-by: Amelia Yukii <amelia.yukii@shourai.de>

View MR for information: !484



Closes #469

Approved-by: Amelia Yukii <amelia.yukii@shourai.de>

see also https://github.com/raszi/node-tmp/issues/295

View MR for information: !453



Closes #436

Approved-by: Essem <smswessem@gmail.com>
Approved-by: Leah <kevinlukej@gmail.com>

View MR for information: !468



Closes #445

Approved-by: Luna <her@mint.lgbt>
Approved-by: Amelia Yukii <amelia.yukii@shourai.de>

View MR for information: !466



Approved-by: Luna <her@mint.lgbt>
Approved-by: Amelia Yukii <amelia.yukii@shourai.de>

View MR for information: !467



Closes #458

Approved-by: Amelia Yukii <amelia.yukii@shourai.de>
Approved-by: Leah <kevinlukej@gmail.com>
Approved-by: Marie <marie@kaifa.ch>

View MR for information: !470



Approved-by: Amelia Yukii <amelia.yukii@shourai.de>
Approved-by: Marie <marie@kaifa.ch>
Approved-by: dakkar <dakkar@thenautilus.net>

View MR for information: TransFem-org/Sharkey!471



Approved-by: Amelia Yukii <amelia.yukii@shourai.de>
Approved-by: Luna <her@mint.lgbt>

We can't make the cookie `HttpOnly` because we're setting it from
Javascript, but I'm not sure it's worth the trouble to redesign that:
`JSON.parse(localStorage.account).token` gives you the token anyway,
hiding the cookie from JS won't offer much protection.

At least we can mark is `Secure` (meaning, only send it over HTTPS)
and _delete it on logout_ (it wasn't!)

not the most elegant solution, but simple and robust

View MR for information: !463



Approved-by: Marie <marie@kaifa.ch>
Approved-by: Amelia Yukii <amelia.yukii@shourai.de>

View MR for information: !461



Approved-by: Amelia Yukii <amelia.yukii@shourai.de>
Approved-by: Luna <her@mint.lgbt>