Attribute Uniqueness Plugin uses wrong subtree on ModRDN

[theSuess]

Issue Description
When using the Attribute uniqueness plugin, restricted to one subtree, moving an object with an already existing attribute to this subtree does not raise any exceptions. It appears that the originating subtree is searched instead.

Package Version and Platform:

• Platform: Containerized Fedora (tested on 33 and 34)
• Package and version: Tested with all versions >= 2.0.2

Steps to Reproduce

1. Create two container objects e.g ou=c1,dc=example,dc=com and ou=c2,dc=example,dc=com
2. Create an entry for the attr-uniq plugin restricted to the c1 subtree, restricting (for example) the mail attribute.
3. Create two objects with the same value for mail in c2 (this should be allowed).
4. Move one object to c1
5. Move the second object to c1. This should raise an exeption as another object with the same value for mail already exists in c1 but works without issues.
6. Additionally, trying to move one of these objects back to c2 raises an exception even though there is no uniqueness constraint on c2.

Expected results
The attr-uniq plugin should prevent invalid move operations.

Additional context
I've tried to get to the root cause of this issue, and debug logs suggest that https://github.com/389ds/389-ds-base/blob/master/ldap/servers/plugins/uiduniq/uid.c#L1395 is called with the old parentDN. However, as this is my first time digging through the codebase I was unable to figure out why this happens.

[mreynolds389]

Downstream bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1990000

[progier389]

IMHO the issue is that we use "sdn" (the target entry parent) instead of "superior" (the renamed entry parent) while calling findSubtreeAndSearch / searchAllSubtrees

[mreynolds389]

Can this backported down to 1.4.3 please?

[droideck]

c7e7259..2aff98c 389-ds-base-1.4.3 -> 389-ds-base-1.4.3
4c5a75f..a3d4f63 389-ds-base-1.4.4 -> 389-ds-base-1.4.4
c7a6796..9cf2517 389-ds-base-2.0 -> 389-ds-base-2.0

[tbordaz]

@droideck would you revisit the fix as it creates a regression detected by IPA (#2000420).
The fix changes the target DN from the source to destination entry of MODRDN. This param is just to prevent Uniqueness checking to fail because of the target entry itself. I think the code was using 'sdn' was possibly valid and I wonder if the test was successful even without the fix.

The scope of testing is defined by the plugin attribute, not by the source or destination entry.

[progier389]

@droideck ,
As the search functions check the suffixes handled by the plugin, IMHO Thierry is wrong and the providing source or destination matters
But the point I missed is that these search functions also used the dn to exclude the source entry from the result set.
So if I understand rightly: ==>
In findSubtreeAndSearch case, we changed the wrong parameter:
it is the "parent" that should be changed to the ndn instead of the "target"
In searchAllSubtrees a new parameter must be added to distinguish the destination dn
(that should be used to check the suffixes handled by the plugin) from the source dn (that should be used to ignore the entry in the result set )