[WIP] Docs updates in preparation for the Sync Streams beta release

[benitav]

Details are in this internal doc https://docs.google.com/document/d/1oP0UNOjpsfSrQ1a2WIhG0A0DYeWU1tTIGZqMMKuqzdE/edit

At a high level, this prioritizes Sync Streams over Sync Rules throughout the documentation and labels Sync Rules as legacy, updates alpha references to beta, fleshed out Sync Streams docs, and also documents new features (e.g. nested subqueries, JOIN syntax, CTEs) that have been added since the alpha release (though not yet released).

Also includes some general polish:

• Sync Streams and Sync Rules casing was made consistent
• sync_rules.yaml references were renamed to sync_config.yaml to better cater for both Streams and Rules
• Added mdx descriptions to pages where I noticed they were missing
• Renamed "dynamic partial replication" to "partial sync"

[cahofmeyr]

When I reviewed the Sync Streams "Quickstart" page, and it explained user-scoped data and parameterized data, I felt we could simplify that because we want to reduce the overall number of new concepts that the user feels they need to go through.

When talking about parameterized data, we referred exclusively to using subscription parameters, but:

• User-scoped data referred to using JWT claims, but if you use something like a org ID or project ID from a JWT, that feels like just another form of parameterized data.
• Even just using a user ID feels like a specific case of parameterizing data.
• Using connection parameters would also be another form of parameterized data.

I ended up editing that section a bit and collapsing the Using Parameters section into it.

[cahofmeyr]

@benitav Suggestions for improvements to the Supported SQL page:

Operators and Functions

When filtering on parameters, operators can only be used in a limited way. Typically only =, IN and IS NULL are allowed on the parameters, and special limits apply when combining clauses with AND, OR or NOT.

I think we should be as specific as possible. Remove "typically" and "special limits apply" and rather say exactly what is and what is not supported (and distinguish Sync Rules vs Sync Streams respectively, if they differ)

Operators

"Arrays:" says the following:

Returns true if the left value is present in the right JSON array.
In data queries, only the left value may be a bucket parameter. In parameter queries, the left or right value may be a bucket parameter.
Differs from the SQLite operator in that it can be used directly on a JSON array.

This seems to be specific to Sync Rules (and uses Sync Rules terminology). Can we update that section to specify what is supported in Sync Streams vs. Sync Rules w.r.t. arrays and the IN operator?

[rkistner]

NOT IN is not supported in sync rules.

[rkistner]

This syntax is not supported in sync rules - should be NOT IN '["draft", "hidden"]'. But the latter version actually fails with the new compiler - need to fix.

[benitav]

Just to confirm, was there a typo and are you saying that the syntax for sync streams should be NOT IN '["draft", "hidden"]', or is the syntax above correct for sync streams and for sync rules it's NOT IN '["draft", "hidden"]'

[rkistner]

Sorry, I confused these.

Sync rules don't support NOT IN at all.

Sync streams should support it (except for a bug), but with the NOT IN '["draft", "hidden"]' syntax.

[rkistner]

OR is also supported in data queries when both sides reference the same bucket parameters.

[rkistner]

This is supported.