Full, verified support for 389 Directory Server

[JayVDZ]

Problem

Until recently the LDAP Connector guide's Supported Directories table claimed "389 Directory Server: Full support including changelog-based delta import". No automated test has ever connected JIM to a 389-ds instance, and the mechanism the claim named, the Generic directory type's changelog-based delta import (cn=changelog / changeNumber in LdapConnectorImport.cs), has no fixture anywhere: it has never been executed against a real directory. The claim has therefore been narrowed to generic-mode support in the docs, and this issue exists to earn the Full Support row back with evidence.

What is wanted

Verified, documented, regression-netted 389-ds support. "Full support" means at least:

• Schema discovery, Full Import, export and changelog-based Delta Import proven against a real 389-ds instance (Retro Changelog plugin), with the external ID handled correctly (entryUUID; confirm plugin availability and defaults on the pinned image).
• Encrypted and unencrypted connection coverage in the RequiresLdaps tier, including the JIM certificate store trust rows (the Integration coverage for connection encryption across every supported directory server type #1141 pattern).
• Integration harness support (a Get-DirectoryConfig entry, populate script, and at least the core scenarios), or a deliberate, recorded decision about which tier carries which proof.
• Docs restored to a Full Support row stating exactly what is verified; roadmap updated accordingly.

Approach

1. PRD and plan first (jim-prd). The PRD must decide the shape of 389-ds coverage across the test tiers before any implementation.
2. Reconcile Integration coverage for connection encryption across every supported directory server type #1141 against the PRD. Integration coverage for connection encryption across every supported directory server type #1141 (connection encryption coverage across directory types, a sub-issue of this one) deliberately deferred its Generic directory type rows pending this holistic view. The PRD decides how the Generic/389-ds rows land so the two pieces of work compose rather than diverge; if the PRD finds a reason to reshape what Integration coverage for connection encryption across every supported directory server type #1141 delivered (fixture design, environment variable surface, CI job shape), that reshaping is in scope here.
3. Implement to the PRD, expecting the first real changelog Delta Import run to surface latent defects in the untested path; fixing those is the point of the work.

Notes

• Proposal artefact with the options considered and the fit between JIM's Generic assumptions and 389-ds (entryUUID, Retro Changelog, paging, TLS) is with the product owner; decision was this issue's approach.
• The 389ds/dirsrv image is maintained by the 389 project and auto-creates an instance on first boot; it would be a test fixture under dependency governance, not a product dependency.
• Validate Isode M-Vault LDAP directory server support #779 (Isode M-Vault validation) is the adjacent precedent: another directory riding the Generic path whose support wants validating. The PRD should consider whether the 389-ds fixture work generalises to that.

Acceptance criteria

• PRD and plan exist and are approved, including the reconciliation of Integration coverage for connection encryption across every supported directory server type #1141's Generic-type coverage.
• Changelog-based Delta Import is proven against a real 389-ds instance somewhere automated.
• Encrypted and unencrypted connection rows for 389-ds run somewhere that gates a merge.
• Docs and roadmap state exactly what is verified; the Full Support row returns only with evidence behind it.