NameAwareAttribute.remove(Name) reports success without removing the value

NameAwareAttribute keeps a Name-keyed view of its values beside the values themselves, and the two go out of step.

add(Name) of a name already held under a different rendering replaces the stored string with the canonical rendering but leaves the view pointing at the old string. A later remove(Name) removes the view entry, fails to find the old string in values, and returns true with the value still held. clear() leaves the view populated, so a following add(Name) of the same name returns false and adds nothing. initValuesAsNames() maps an LdapName element to its toString(), so remove(Name) cannot remove the object actually held.

Through DirContextAdapter, with the directory rendering the DN with a space after the comma:

BasicAttributes attrs = new BasicAttributes();
BasicAttribute member = new BasicAttribute("member");
member.add("cn=John Doe, ou=People");
attrs.put(member);
DirContextAdapter adapter = new DirContextAdapter(attrs, LdapUtils.newLdapName("cn=group"));
adapter.setUpdateMode(true);
adapter.addAttributeValue("member", LdapUtils.newLdapName("cn=John Doe,ou=People"));
adapter.removeAttributeValue("member", LdapUtils.newLdapName("cn=John Doe,ou=People"));
// the member is still held; the modification items never remove it

remove(int) had the same class of problem in #437. Observed on main at e77c93f3.

Start by locating NameAwareAttribute and read add(Name), remove(Name), clear(), and initValuesAsNames(); then trace how DirContextAdapter exercises these methods. Reproduce the rendering-mismatch example and verify that remove(Name) removes the held value, clear() resets the name view, and LdapName elements can be removed successfully.