[Bug]: ldap.managed attribute ordering

What happened?

In a state like the following, the attributes list (here top and organizationUnit) might be written in one order

manage-ldap:
  ldap.managed:
    - connect_spec:
        url: ldapi://%2frun%2fslapd-myidm.socket
    - entries:
        - ou=people,dc=example,dc=com:
            - delete_others: True
            - replace:
                objectClass:
                  - top
                  - organizationalUnit
                ou:
                  - people

but the LDAP server might store the change in a different order:

# ldapsearch -LLLH ldapi://%2fvar%2frun%2fslapd-myidm.socket ou=people objectClass
...
dn: ou=people,dc=example,dc=com
objectClass: organizationalUnit
objectClass: top

There are two problems:

1. The state is not idempotent - there are always changes reported - applying them does not resolve them, because the LDAP server sticks to its order.
2. The changes output does not indicate what the difference with the reported changes is, as the changes dict is "prettified" with attribute sorting.

          ID: manage-ldap
    Function: ldap.managed
      Result: None
     Comment: Would change LDAP entries
     Started: 12:48:46.085695
    Duration: 278.825 ms
     Changes:
              ----------
              ou=people,dc=example,dc=com:
                  ----------
                  new:
                      ----------
                      objectclass:
                          - organizationalUnit
                          - top
                  old:
                      ----------
                      objectClass:
                          - organizationalUnit
                          - top

To make the state idempotent, one needs to write the attributes in the same order as expected by the LDAP server.

I am not certain if this behavior is specific to the LDAP implementation I am using the state with (389DS), but as it is not convenient for a user writing a state to guess what order the LDAP server might expect (to avoid endless changes upon deployment), I think the module should internally sort the attribute values.

However, this might need exceptions or a boolean toggle, as ordering might be important (and not mangled by the LDAP server) for some specific attributes (for example mail).

Type of salt install

pip (git)

Major version

3006.x

What supported OS are you seeing the problem on? Can select multiple. (If bug appears on an unsupported OS, please open a GitHub Discussion instead)

sles-15-sp5

salt --versions-report output

Salt Version:
          Salt: 3006.19+0.gc9c5ab41bd

Python Version:
        Python: 3.11.14 (main, Nov 20 2025, 22:16:35) [GCC]

Dependency Versions:
          cffi: Not Installed
      cherrypy: Not Installed
  cryptography: Not Installed
      dateutil: Not Installed
     docker-py: Not Installed
         gitdb: Not Installed
     gitpython: Not Installed
        Jinja2: 3.1.6
       libgit2: Not Installed
  looseversion: 1.3.0
      M2Crypto: Not Installed
          Mako: Not Installed
       msgpack: 1.1.2
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     packaging: 25.0
     pycparser: Not Installed
      pycrypto: Not Installed
  pycryptodome: Not Installed
        pygit2: Not Installed
  python-gnupg: Not Installed
        PyYAML: 6.0.3
         PyZMQ: Not Installed
        relenv: Not Installed
         smmap: Not Installed
       timelib: Not Installed
       Tornado: 4.5.3
           ZMQ: Not Installed

System Versions:
          dist: sles 15.7
        locale: utf-8
       machine: x86_64
       release: 6.18.3-1-default
        system: Linux
       version: SLES 15.7

Start from the ldap.managed state implementation and trace how LDAP attribute values are compared and how the changes dictionary is formatted. Reproduce the ordering case, then define and test behavior that avoids repeated changes while preserving meaningful ordering differences and accurately reporting old and new values.