Don't store entries with a usercertificate in the LDAP cache

usercertificate often has a subclass and both the plain and
subclassed (binary) values are queried. I'm concerned that
they are used more or less interchangably in places so not
caching these entries is the safest path forward for now until
we can dedicate the time to find all usages, determine their
safety and/or perhaps handle this gracefully within the cache
now.

What we see in this bug is that usercertificate;binary holds the
first certificate value but a user-mod is done with
setattr usercertificate=<new_cert>. Since there is no
usercertificate value (remember, it's usercertificate;binary)
a replace is done and 389-ds wipes the existing value as we've
asked it to.

I'm not comfortable with simply treating them the same because
in LDAP they are not.

https://pagure.io/freeipa/issue/8986

Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Francois Cami <fcami@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>

ipapython/ipaldap.py

@@ -1823,9 +1823,17 @@ class LDAPCache(LDAPClient):
                         entry=None, exception=None):
         # idnsname - caching prevents delete when mod value to None
         # cospriority - in a Class of Service object, uncacheable
-        # TODO - usercertificate was banned at one point and I don't remember
-        #        why...
-        BANNED_ATTRS = {'idnsname', 'cospriority'}
+        # usercertificate* - caching subtypes is tricky, trade less
+        #                    complexity for performance
+        #
+        # TODO: teach the cache about subtypes
+
+        BANNED_ATTRS = {
+            'idnsname',
+            'cospriority',
+            'usercertificate',
+            'usercertificate;binary'
+        }
         if not self._enable_cache:
             return