[#1031] Keep the replication test's admin and replication ports out of the ephemeral range

[vharseko]

Fixes #1031

Why

Test replication numbers its three servers N389 / N636 / N4444 / N8989. At N=3 two of the twelve ports — the admin connector 34444 and the replication port 38989 — land inside the Linux default net.ipv4.ip_local_port_range (32768 60999), the block the kernel hands out as source ports for outgoing connections. Whatever on the runner happens to be dialling out at the wrong moment holds the port, and the third server cannot bind it.

Seen twice on 2026-09-11, both at Setup OpenDJ-3 with replication, both on JDBC-only branches whose sibling legs were green:

• run 34564104369, build-maven (ubuntu-latest, 17) — caught by setup's own port check: ERROR: Unable to bind to port 34444.
• run 34565184252, build-maven (ubuntu-latest, 21) — past the check, configured, then Error Starting Directory Server. Error code: 1 after 5.5 s, the point at which a normal start binds its connection handlers. start-ds exit 1 there means the server's own System.exit(1) on an InitializationException (a kill would leave server.starting in place and hang WaitForFileDelete); the only thing that differs between the identically configured opendj2 and opendj3 is the port numbers.

Only 34444 was ever named, and that is what the kernel predicts: connect() autobinds ports of the parity of the range's lower bound (even), bind(0) takes the other parity — 34444 is even, 38989 is odd. Both move anyway; they live in the same block.

What

Renumber the administrative ports of servers 2 and 3 into the block next to server 1:

	before	after
OpenDJ-2 admin connector	24444	4445
OpenDJ-2 replication	28989	8990
OpenDJ-3 admin connector	34444	4446
OpenDJ-3 replication	38989	8991

Server 2's ports were below the boundary and not at risk; they move so the scheme stops being positional — 4444/4445/4446 and 8989/8990/8991 are contiguous and a fourth server extends them without anyone re-checking where the ephemeral range starts. LDAP/LDAPS ports (1389/2389/3389, 1636/2636/3636) are unchanged. None of the new numbers collides with the other ports of the same job (1389, 1636, 4444, 5432, 9042); 8990 occurs in the repository once, as a HostPort label in ConnectFailureReporterTest that never opens a socket. A comment above the step records the constraint.

Verified

• The step body, extracted verbatim from the edited workflow, run locally against a built package: all three servers up, replication enabled 1↔2 on 4445/8990 and 2↔3 on 4446/8991, both initializations Base DN initialized successfully, both 100 000-entry checks passed, all instances stopped, no listeners left.
• YAML parses; the step keeps exactly if / name / run / timeout-minutes; no old number remains under .github/.

Not in this PR

A diagnostic if: failure() step dumping opendj3/logs/server.out and ss -tanp — the second failure's port was never named because the detail log it points at is gone (#1030). Worth adding separately so the next intermittent start failure explains itself.