This PR seeks to address trigger.dev's WAL lag issues by adding two optimisations to where clause filtering:

• Allow multiple conditions in a where clause to be optimised (not just one)
• Optimise where clauses that have a condition in the form 'array_field @> array_const'

Allow multiple conditions in a where clause to be optimised (not just one)

This feature alone should halve the processing time for trigger.dev as they have many where clauses in the form WHERE runtimeEnvironmentId = ? AND batchId = ? where if a change matched the runtimeEnvironmentId it would then have to iterate through the batchIds. Now it doesn't - the batchId condition is indexed as well.

Optimise where clauses that have a condition in the form 'array_field @> array_const'

Trigger.dev's other problematic where clauses are in the form WHERE runtimeEnvironmentId = ? AND runTags @> ? and this feature optimises the @> operation. The algorithm for this optimisation can be seen in the InclusionIndex module.

Comparing the performance of this index against the current method shows quite a dramatic difference:

Here you can see it performs well with 100k shapes (which for trigger.dev would be 100k shapes with the same runtimeEnvironmentId, in other words 100k shapes per user)

Both of the charts above are based on a shape array size of 3 and a change array size of 10 which is typical for trigger.dev.

The algorithm seems to scale roughly linearly with change array size:

The algorithm seems to scale well with shape array size for a fixed change array size (10):