Fix LDAP component to use dedicated user instead of operator user

[delgod]

Issue

Fixes #966

The LDAP component currently uses the operator user to connect to PostgreSQL, which violates the principle of least privilege. Each component should have its own dedicated user with minimal necessary permissions.

Solution

This PR implements a dedicated LDAP user for PostgreSQL connections used by the LDAP synchronization service:

Key Changes:

1. Add LDAP user constants and system configuration:

   • Added LDAP_USER = "ldap" and LDAP_PASSWORD_KEY = "ldap-password" constants
   • Added LDAP_USER to SYSTEM_USERS list for proper management
   • Imported new constants in charm.py

2. Implement LDAP user creation with minimal privileges:

   • Generate LDAP password during leader election alongside other system passwords
   • Create LDAP user in _start_primary method with CREATEROLE privilege only
   • Ensures minimal necessary permissions for LDAP sync operations

3. Update LDAP sync to use dedicated user:

   • Modified _setup_ldap_sync to use LDAP_USER and LDAP_PASSWORD_KEY
   • Replaced operator user credentials with dedicated LDAP user credentials
   • Maintains security isolation between components

4. Comprehensive test coverage:

   • Added LDAP user to integration password rotation tests
   • Extended unit tests for get-password and set-password actions
   • Ensures LDAP user is properly tested in all password management scenarios

5. Complete documentation updates:

   • Added LDAP user to internal users documentation with privilege explanation
   • Updated PostgreSQL roles dump example to include ldap user
   • Extended password management documentation to include all system users

Security Benefits:

• Principle of least privilege: LDAP user has only CREATEROLE privilege needed for LDAP sync
• Component isolation: LDAP service no longer uses operator user credentials
• Audit clarity: LDAP operations are clearly identifiable in logs and monitoring

Backward Compatibility:

• Existing deployments will automatically create the LDAP user during next restart
• No manual intervention required for existing LDAP integrations
• Password management actions now support the new LDAP user

Checklist

• I have added or updated any relevant documentation.
• I have cleaned any remaining cloud resources from my accounts.

[sinclert-canonical]

A couple of thoughts about these changes, in case the PR was not created for demo purposes:

• When I designed the whole LDAP integration, one key aspect considering PostgreSQL resource ownership model, was which user was going to be the one "acquiring" the ownership of deleted user resources once they get removed from the connected LDAP server. I went for operator, as it seems the all power user that will never go away.
• Even if the CREATEROLE PostgreSQL privileges allowed the proposed user to alter / create/ drop users, I do not think it will allow it to read from system views such as pg_user and pg_group (see usage), nor to reassign resources before dropping a role (see usage).

---

I think separating concerns in terms of which system user is in charge of running the LDAP sync service is a great idea. We just need to make sure we are comfortable with it owning the deleted-users resources, and provide it enough privileges.