Fix CodeQL note-severity alerts: confusing overloads with subtype parameters

[vharseko]

Addresses the java/confusing-method-signature alerts. Most of them cannot be acted on, but the ones which can were worth looking at: one was a latent StackOverflowError.

A recursive overload which could never have worked

AbstractPBKDF2PasswordStorageScheme had two overloads whose parameter types are related by inheritance:

private SecretKey encodeWithRandomSalt(ByteString plaintext, byte[] saltBytes, int iterations) {
    random.nextBytes(saltBytes);
    return encodeWithRandomSalt(plaintext, saltBytes, iterations);   // plaintext is a ByteString...
}                                                                     // ...so this calls itself

private SecretKey encodeWithRandomSalt(ByteSequence plaintext, byte[] saltBytes, int iterations) {
    random.nextBytes(saltBytes);
    return encodeWithSalt(plaintext, saltBytes, iterations);
}

ByteString implements ByteSequence, so inside the first overload the most specific applicable method is itself: any call would have recursed until the stack was exhausted. It survived because it is dead code — encodePassword() and encodeAuthPassword() both pass a ByteSequence and bind to the second overload. The dead overload is removed.

While there, the file received the license header it was missing. Its original attribution is left to the maintainers: the file was contributed in 2022 without a header, and this change does not invent one.

Overloads selected by the static type in the replication CLI

ReplicationCliMain overloaded two private methods on MonoServerReplicationUserData and on three of its subtypes (DisableReplicationUserData, StatusReplicationUserData, PurgeHistoricalUserData), so which method runs depends on the declared type of the variable rather than on the object. The two general overloads are renamed after what they actually do — they prompt through sourceServerCI and read the source server arguments:

• getConnection(MonoServerReplicationUserData) → getConnectionToSourceServer(...)
• initializeWithArgParser(MonoServerReplicationUserData) → initializeWithArgParserForSourceServer(...)

The compiler identified every call site of both: initialize-all, pre and post external initialization, and status.

Alerts deliberately left open (33)

• 10 — the implementation of the SLF4J Logger interface in OpenDJLoggerAdapter (trace/debug/info/warn/error(String, Object) next to (String, Throwable)): the shape is imposed by the interface.
• ~19 — public overload sets of the SDK and of the plugin API: Connection.add(Entry|AddRequest), ChangeRecordWriter.writeChangeRecord(...) (four), Responses.newSearchResultEntry, LDIF.toLDIF, ByteStringBuilder.appendBytes, Converters.to/from (three), DirectoryServerPlugin.isConfigurationAcceptable, MonitorData.add, OperationContext.getCSN, SNMPMonitor.counter32Value/gauge32Value, AbstractIndexTableModel.compareNames, TemplateValue.append and the two menu callbacks of ManageTasks. Renaming any of them is an API break.
• 2 — SASLBindClientImpl.handle(ChoiceCallback) and handle(TextInputCallback): two members of a deliberate family of eight handle(XxxCallback) methods which handle(Callback[]) dispatches to; renaming two of the eight would make the family inconsistent.
• 2 — ConsistentHashDistributionLoadBalancer.synchronize(SearchResultHandler|IntermediateResponseHandler): the parameter types are unrelated, so no call can select the wrong one.

Testing

opendj-server-legacy (-Pprecommit): PKCS5S2PasswordStorageSchemeTestCase (53), PBKDF2PasswordStorageSchemeTestCase (39), PBKDF2HmacSHA256PasswordStorageSchemeTestCase (39), PBKDF2HmacSHA512PasswordStorageSchemeTestCase (39) — 170 tests, all passing. The password storage schemes are the only place where code was removed; the replication CLI changes are private renames, verified by the compiler.