Add the Largest Group Subscription filter back

[ianswett]

Allows faster Track joining in the presence of reordering.

Fixes #1358

[afrind]

Briefly covered this in the interim today but did not have time to discuss.

[gwendalsimon]

We discussed Largest Group quite a long time ago, didn't we?

One point is kind of philosophical: FETCH is for the past, SUBSCRIBE is for the present and the future. Largest Group for SUBSCRIBE breaks this rule.

More practically, we have the case where the Relay does not have the first Objects of the current group (because it does not have a cache, or because these Objects are too old to be delivered from cache, or because it did not have any active Subscription at the time these Objects were delivered). It may send the same request upstream, but the upstream Relay or the Original Publisher may have started a new Group. To be safe, the Relay should send a FETCH instead.

Why is the combination of SUBSCRIBE Largest Object + Joining FETCH Offset 0 not good?

[ianswett]

The issue describes the problem, but if we do something along the lines of merging Subscribe and Fetch (#1377) those would also be resolved.

[martinduke]

I am not convinced that "FETCH everything, but return objects out of order" is a real use case. If it is a real use case, then let's just make a FETCH parameter that does this rather than have a SUBSCRIBE filter that affects how FETCH works.

One problem with this PR is that the notion of SUBSCRIBE that returns "new objects" < largest_location was expressly separated from FETCH, and this mingles them in a way that might cause problems.

[afrind]

Discussed 12/1:

Parking until we have a larger discussion on joining fetch concerns.