oracledb_cdc: remove primary key ordering from unfiltered snapshot

[josephwoodward]

Problem

By default, OracleDB uses heaped tables which aren't sorted by primary key, meaning snapshotting ordered by primary key can incur high disk I/O as every single row lookup via ROWID forces Oracle to jump to a different physical data block on disk.

Solution

As this is a full table scan, and not batched/chunked into ranges we can remove ordering which improves overall read performance.

Proof of Work

AWS Benchmark

Benchmarks went from ~9.8MB/s (post cache-warm) to a consistent 98MB/s:

Local Benchmark:

Before: Avg. ~40MB/s

After: Avg. ~51MB/s

[claude]

snapshot_max_batch_size now carries two unrelated meanings depending on whether the table happens to have a snapshot_filters entry: for filtered tables it is the page size of the keyset-pagination query, and for every other table (the default, since snapshot_filters is optional) it degrades to "how often ctx.Err() is polled" — see snapshot.go#L362-L381.

This is a material UX regression under CONTRIBUTING §1.1.3 ("UX should be intuitive and require minimal explanation") and §3.1.5 (consistency with the rest of the fleet, where snapshot_max_batch_size uniformly means rows-per-fetch). The description text itself is the evidence — it has to explain two divergent behaviours for one knob.

Concretely: a user who raised snapshot_max_batch_size to tune snapshot throughput — exactly what docs/benchmark-results/oracledb-cdc.md documents with snapshot_max_batch_size: 160000 — now gets no throughput effect at all on the default path, silently.

Suggested fix: keep the knob meaning "rows fetched per round trip" on both paths by wiring it into the driver's prefetch/array-fetch size for the full-scan cursor, and use a separate fixed internal constant for the cancellation-poll interval. If the two really must differ, a dedicated field for the scan path would be clearer than overloading this one.

[josephwoodward]

I'm not sure we want snapshot_max_batch_size to be the prefetch_rows value, it would be better to have that as a dedicated config and deprecate snapshot_max_batch_size if needed.

[claude]

This change is justified purely on throughput grounds — the doc comment here and the inline comment at snapshot.go#L232-L234 both claim the unordered scan is faster than the previous ORDER BY keyset pagination — but no benchmark evidence ships with it.

CONTRIBUTING §1.3.4/§1.3.5 requires both local and real-endpoint benchmarking at various throughput levels, with results recorded under docs/benchmark-results/. docs/benchmark-results/oracledb-cdc.md already has a "Snapshot Results" section, and it is left untouched by this PR — so the recorded numbers now describe a code path that no longer runs for unfiltered tables, and were captured under a snapshot_max_batch_size: 160000 setting whose meaning this PR changes.

Suggested fix: re-run the snapshot benchmarks against the new scan path and update docs/benchmark-results/oracledb-cdc.md, so the performance claim in this comment is backed by recorded numbers rather than an assertion about Oracle's optimizer.

[josephwoodward]

Benchmarks included in proof of work. Will look to update these as a separate PR.