In the current code, LimitRecordCursorFactory.toPlan() calls calculateSize() to resolve the effective LIMIT bounds. This executes the complete query. This PR lets toPlan() work with the information that's already available and never make the expensive call.

The PR also resolves other related issues with LimitRecordCursorFactory:

• avoids calculateSize() in hasNext() when LIMIT bounds are non-negative (no need to count from the back)
• avoids calculateSize() in size(), propagating -1 if the size isn't cheaply available

On the other hand, the new code calls baseCursor.size() eagerly in of(). This provides the invariant: "base row count missing indicates the expensive count is unavoidable".

The PR clears up the semantics of LIMIT, which are currently in contradiction with the specification in the docs.

Cleaned-up LIMIT semantics

The main complication in the semantics stems from LIMIT args being allowed to be both positive and negative, and even a mix of both. Here are the new rules (m and n are positive numbers, so -m is a negative number):

• LIMIT n = LIMIT n, 0 = LIMIT 0, n = LIMIT n, = LIMIT , n: take first n rows
• LIMIT m, n: take rows from the zero-based range [m, n) (left-inclusive, right-exclusive). If m > n, implicitly swap them.
• LIMIT -n= LIMIT -n, 0 = LIMIT -n,: take last n rows
• LIMIT -m, -n: take rows from the range [-m, -n), where -1 denotes the last row, -2 next-to-last, and so on. If m < n, implicitly swap them.
• LIMIT m, -n: take rows from the range [m, -n). In other words, skip the first m rows, and drop the last n rows. These arguments will not be swapped.

Additional bugfixes

Since it touches LimitRecordCursorFactory.calculateSize() andskipRows(), this PR surfaced a number of bugs in these methods in other cursor classes. It fixes them.