Reduce stream-server delay if `Continued: 0` is passed

[dstillman]

And update clients to pass Continued: 0 when they know they have nothing else to upload.

Requests with Continued: 1 will wait longer (currently 30 seconds), while requests that don't specify will use the default debounce (currently 3 seconds)

[dstillman]

Will require a change to stream-server to use, say, 250 ms instead of 3 seconds if continued: false is passed

https://github.com/zotero/stream-server/blob/7e2e57d49ad300dd595ab9e239afe908525097b4/server.js#L85
https://github.com/zotero/stream-server/blob/7e2e57d49ad300dd595ab9e239afe908525097b4/config/default.js#L33
https://github.com/zotero/stream-server/blob/7e2e57d49ad300dd595ab9e239afe908525097b4/server.js#L65

Why not 0? Because we do want to account for the possibility of Aurora replica lag:

As a result, all Aurora Replicas return the same data for query results with minimal replica lag. This lag is usually much less than 100 milliseconds after the primary instance has written an update. Replica lag varies depending on the rate of database change. That is, during periods where a large amount of write operations occur for the database, you might see an increase in replica lag.

But PHP + Redis + stream server + 250 ms + latency to user + client kicking of a new sync is probably safe…

[abaevbog]

The continued property in the dataserver is set when passed there's a header passed by the client. I assumed the purpose of this variable is to tell the streaming server that there are more messages coming after this one when the notifications are being sent.
I kept track of when the last item from the array of messages is reached and set continued=false to tell streaming server that there are no more messages. Then, in the streaming server, I added a few lines to delay for 250ms when message.continued == false

[dstillman]

Sorry, should've given you more context here. It's the client that communicates whether there are more requests coming, with either Continued: 0 or Continued: 1, not the dataserver itself. (That loop in the dataserver is for sending notifications with library ids, not individual item ids, so the order of those and which one is last doesn't matter — the same continued will apply to all library ids being modified by a given request (which will usually only be a single one anyway).

The clients don't yet do this, so you can't test with an existing client. We'll need to modify the sync logic in the clients to do this, but that's more complicated and we'll do it separately.

[abaevbog]

I see! Yes, I was missing some context here. I will keep only the PR for the streaming server and cancel one for the dataserver