Add knowage-enhanced-ldap-security-provider module

[egwada]

Fixes three critical bugs in the existing knowageldapsecurityprovider for multi-OU Active Directory environments:

• bindWithCredentials corrupted service account DN on subtree search
• DN_POSTFIX conflated search base with DN suffix, blocking multi-OU search
• FullLdapSecurityServiceSupplier built user DN by concatenation instead of subtree search (SUBTREE_SCOPE from BASE_DN)

New features:

• Automatic user provisioning on first LDAP login (AUTO_CREATE_USER)
• Role sync: LDAP groups matching Knowage role names are persisted in SBI_EXT_USER_ROLES at each login (visible in admin UI)
• Encrypted password support via ENC(...) wrapper
• Fallback to internal authentication when LDAP is unavailable
• Docker OpenLDAP test environment (docker-compose.test-ldap.yml + test-ldap/)

[github-actions]

CLA Assistant Lite bot:
Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

---

I have read the CLA Document and I hereby sign the CLA

---

_{You can retrigger this bot by commenting recheck in this Pull Request}

[eng-dedalus]

Hi @egwada ,
first of all, thank you very much for this contribution and for the work you put into it — we really appreciate the effort behind this PR.

We reviewed the proposal and we would like to clarify one important point to make sure we are understanding the intended flow correctly.

In the current codebase, we already support two different LDAP-related scenarios:

LDAP for authentication only, while authorization/user management stays in Knowage.
In this case, the user must already exist in the Knowage DB, and LDAP is only used to validate credentials.

Full LDAP flow, where the user profile is built directly from LDAP data.
In this case, the user is not expected to be provisioned/persisted in the Knowage DB as part of the login flow.

From your PR description, it seems that the new module introduces automatic user provisioning when an LDAP-authenticated user does not already exist in the Knowage DB, and also synchronizes LDAP roles into the application DB.

Our doubt is about how this design is meant to fit with the second scenario above, i.e. the full LDAP flow.
In particular, it seems that your implementation introduces persistence/synchronization into the Knowage DB as part of the authentication flow, while our current full LDAP approach does not rely on that model.

Could you please clarify whether we are interpreting your proposal correctly?
More specifically:

is the automatic provisioning of users into the Knowage DB intended to be mandatory in your approach?
are LDAP roles always meant to be synchronized into the DB?
how should this module behave in a scenario where LDAP is expected to handle both authentication and roles/groups without persisting the user in the application DB?
Thanks again for the contribution — it is genuinely appreciated.