Don't revalidate old live requests

[KyleAMathews]

Versions

• Client: Any
• Electric: latest

Bug description
I was helping debug an odd problem reported by a user on Discord — when he started his app he's seeing ~100 live requests with empty body responses before it stabilizes into normal long polling.

At first I suspected it was a proxy caching the data but two things that disproved that theory was a) the response headers had a cloudflare cdn header saying the request was REVALIDATED and then also as he was on Electric Cloud, I could see in the backend that all the quickly repeating calls were actually arriving to the cloud electric instance.

Looking closer at the headers arriving in the backend — all the quickly resolved requests have the same If-None-match request header which the server immediately returned a 304 from.

The root issue is we're expecting unique cursors to serve as cache busters. But caches/proxies can sometimes ignore changing query parameters.

So we should also add the cursor to the etags we generate as another way of preventing caches from holding onto live requests. And also pass the etag cursor to the cursor generating function to prevent us from returning the same etag similar to #1856

Possibly, in retrospect, that's all we need and we don't need to set the cursor in the query param 🤔 — my initial PR for reference #1826 — something to test to possibly remove the cursor query param for v2.

Expected behavior
No proxy will cache or revalidate live requests.

[msfstef]

Is there a reason we're adding etags and revalidating live requests at all? We could just skip the if-none-match check and not attach etags to live responses.