Bump ldap3 to version 2

[matthew-mcallister]

ldap3 now distinguishes between single- and multi-valued attributes and converts attributes to python data types, which requires several internal changes.

Basically, instead of getting

{
   'cn': ['Matthew McAllister'],
   'loginShell': ['/bin/bash'],
   'uidNumber': ['28108'],
   'homeDirectory': ['/home/m/ma/mattmcal'],
   'gidNumber': ['1000'],
   'objectClass': ['ocfAccount', 'account', 'posixAccount'],
   'creationTime': ['20130909235546Z'],
   'uid': ['mattmcal'],
   'calnetUid': ['1031366']
}

you get

{
    'cn': ['Matthew McAllister'], 
    'loginShell': '/bin/bash',
    'uidNumber': 28108,
    'homeDirectory': '/home/m/ma/mattmcal',
    'gidNumber': 1000
    'objectClass': ['ocfAccount', 'account', 'posixAccount'],
    'creationTime': datetime.datetime(2013, 9, 9, 23, 55, 46, tzinfo=OffsetTzInfo(offset=0, name='UTC')),
    'uid': ['mattmcal'],
    'calnetUid': 1031366,
}

This change makes ocflib handle LDAP attributes internally as python data types instead of strings and adjusts for the fact that single-valued attributes are no longer wrapped in a list. I don't think we have any other code that directly handles LDAP attributes at the moment, so nothing else should have to change.

What's awkward about this is that we make changes to LDAP by writing an LDIF, so currently ocflib still has to convert to strings at write time. If we ever figure out how to authenticate using the ldap3 package, though, it will be good for ensuring code is consistent with the LDAP schema. Also, apparently the University's LDAP schema is such that everything is still a list of strings, so code reading from that didn't really change.

[jvperrin]

There's definitely code that handles attributes outside of ocflib though, mostly just to unpack a single value from a list, like in ocfweb stats. I'm sure there's other uses too that I haven't found, so that will cause some problems. Maybe we can have ocflib updated and the ocfweb quickly updated afterwards? I imagine there's some LDAP usages in utils too that use ocflib, but I haven't looked.

[chriskuehl]

you'll need to build a new debian package for python3-ldap3 before we can merge this

[matthew-mcallister]

@jvperrin Good catch on the ocfweb stats page. I'm pretty sure so far we've been updating ocflib and ocfweb at nearly the same time, as you suggested.

You're right that utils does have some ldap3 code. If we're going to install a new version of the ldap3 package as @chriskuehl says, then that means we'll have to update utils as well (not as urgent, but this will break e.g. ldap-lint).