[#860] Serve JDBC cursor repositioning from the fetched buffer and grow batches adaptively

[vharseko]

Fixes #860 (reported in discussion #859: ~52 MB/s of database network traffic on a ~13k-entry directory).

Problem

JDBCStorage.CursorImpl fetched eager batches of 1000 (k,v) rows and every positionToKeyOrNext() discarded the buffer and re-fetched a fresh batch — even when the requested key was already buffered. DN2ID.ChildrenCursor repositions once per child, so a one-level search enumerating N children transferred N × 1000 rows instead of ~N. hasSubordinates() and subtree delete hit the same pattern.

Changes

• positionToKeyOrNext() is served from the already-fetched buffer: buffered rows are the contiguous sorted rows following the current one (byte order matches the database binary collation), so forward repositioning within the fetched range runs no SQL at all. The ChildrenCursor pattern collapses from N × 1000 rows to ~N rows total.
• Adaptive batch sizing: cursors start at org.openidentityplatform.opendj.jdbc.fetchsize.initial (default 32) and grow geometrically to fetchsize (default 1000) while reads stay sequential; a jump outside the buffered range resets the size. Most cursors read only a handful of rows (hasSubordinates reads 1–2), so eager 1000-row fetches were pure overhead.
• Oracle: create the cursor index on (k) in openTree — previously only PostgreSQL and MySQL got it, leaving Oracle keyset-pagination queries (where k>? order by k) unserved by the (h,k) primary key. MSSQL keeps no index: varbinary(max) cannot be an index key column (documented in a comment).
• isExistsIndex now calls getIndexInfo with approximate=true — with false the Oracle driver runs ANALYZE on every metadata check.

Expected effect

Scenario	Before	After
One-level search, N children (flat tree)	N × 1000 rows	~N rows
One-level search, deep tree (miss per child)	N × 1000 rows	N × 32 rows
hasSubordinates per returned entry	1000 rows	32 rows
Subtree scope set (~4000 rows)	5 fetches	~7 fetches, same volume

Tests

• testPositionToKeyOrNextServedFromBuffer — asserts via a fetch counter that repositioning within the buffer runs no SQL, batch growth follows the 2→8 schedule, and a ChildrenCursor-style sibling scan over 39 rows takes ≤8 fetches (38 before the fix).
• testCursorKeyOrderIsUnsigned — {0x7F} vs {0x80,0x01} keys verify the database collates keys in unsigned byte order, which the buffer-serving logic relies on.
• Ran PgSqlTestCase and MySqlTestCase locally: 37 tests each, 0 failures. Oracle/MSSQL are covered by CI.