fix: only retry urldecoded password when decoding changes it (LDAP badPwdCount double-increment)

[mvanhorn]

• Resolves: [Bug]: a wrong password will trigger badPwdCount twice in ldap #33657

Summary

When a wrong password is entered for an LDAP or Active Directory user, the directory's failed-login counter is increased by two instead of one. Administrators who lock accounts after three failed attempts therefore find users locked out after only two mistakes, which causes avoidable lockouts and support load.

The cause is in the password check inside the user manager. After the first authentication attempt with the plain password fails, the method decodes the password and then tries every backend a second time. That second pass exists so that non-ASCII passwords sent over HTTP basic auth, which arrive percent-encoded, can still be verified. The problem is that the second pass ran unconditionally, even when the password contained nothing to decode, so an ordinary wrong password produced two identical authentication attempts and two directory binds for a single login.

This change performs the second attempt only when decoding actually changes the password. When decoding leaves the password unchanged, the method now returns right after the first attempt, so one wrong password results in exactly one directory bind and one counter increment. The compatibility path for genuinely percent-encoded passwords is preserved: when decoding does change the value, the second attempt still runs against the decoded password.

Two unit tests were added. The first checks that a wrong password with nothing to decode reaches the backend exactly once. The second checks that a percent-encoded password still triggers a second attempt with the decoded value and authenticates when the decoded form is accepted.

Fixes #33657

TODO

Nothing outstanding. The change is self-contained and covered by the added tests.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI

AI was used for assistance.