[#1023] Delete every objectClass value a modification asks for

[vharseko]

Fixes #1023

The defect

Entry.removeObjectClassAttribute() returns out of the whole method on the first value it
removes, instead of breaking out of the search through the object classes of the entry and
carrying on with the next value of the modification:

    for (ByteString v : attribute)          // the values the modification deletes
    {
      String ocName = toLowerName(rule, v);

      for (ObjectClass oc : objectClasses.keySet())
      {
        if (oc.hasNameOrOID(ocName))
        {
          objectClasses.remove(oc);
          return true;                      // <- the remaining values are never looked at
        }
      }

      allSuccessful = false;
      missingValues.add(v);
    }

Every delete: objectClass takes this path (LocalBackendModifyOperation.processDeleteModification()
-> Entry.removeAttribute(Attribute, Collection) -> removeObjectClassAttribute()), so a
modification which deletes several object classes drops only the first of them, keeps the rest on
the entry, and answers SUCCESS.

The early return hides missing values as well: missingValues - which the core turns into
NO_SUCH_ATTRIBUTE - is only filled for the values examined before the first removal, so deleting
a class the entry has together with one it does not have succeeded silently.

Single-valued deletes and deletes of the whole objectClass attribute are unaffected, which is why
this has gone unnoticed. The same code is in WrenSecurity/wrends, so the defect is inherited from
upstream rather than introduced here.

The fix

Break out of the inner loop and carry on with the next value, the way the non-objectClass branch of
removeAttribute() walks every value of the modification.

The return value keeps the meaning this branch has always given it (allSuccessful), so the
client-visible change is confined to delete: objectClass: every value is now deleted, and a value
the entry does not have raises NO_SUCH_ATTRIBUTE instead of succeeding silently - unless the
permissive modify control is used, which drops the missing values as before. The other callers of
Entry.removeAttribute(Attribute, Collection) - the old RDN handling of LocalBackendModifyDNOperation

• ignore the return value and only read the missing values.

Tests

Two tests in TestEntry, both failing before the fix:

• testRemoveSeveralObjectClassValues - deleting organizationalPerson and inetOrgPerson in one
  call left inetOrgPerson on the entry.
• testRemoveObjectClassValuesOneOfWhichIsMissing - deleting inetOrgPerson together with domain,
  which the entry does not have, claimed success and reported no missing value.

Local run of TestEntry,ModifyOperationTestCase,EntrySchemaCheckingTestCase: 981 tests, 0 failures.

Note on merge order

PR #1022 touches the same method (it resets the cached objectClass attribute next to
objectClasses.remove(oc)), so whichever of the two lands second conflicts in this hunk. The
resolution is to keep both changes: the reset of the cached attribute, and matchFound / break
in place of the early return.