Add two global ipaConfig options to disable undesirable writes that have
performance impact.
The "KDC:Disable Last Success" will disable writing back to ldap the last
successful AS Request time (successful kinit)
The "KDC:Disable Lockout" will disable completely writing back lockout
related data. This means lockout policies will stop working.

https://fedorahosted.org/freeipa/ticket/2734

If a user become locked due to too many failed logins and then were
unlocked by an administrator, the account would not lock again. This
was caused by two things:

 - We were incrementing the fail counter before checking to see if the
   account was already locked out.
 - The current fail count wasn't taken into consideration when
   deciding if the account is locked.

The sequence was this:

1. Unlocked account, set failcount to 0
2. Failed login, increment failcount
3. Within lastfailed + lockout_duration, still locked. This skips
   update the last_failed date.

So I reversed 2 and 3 and check to see if the fail count exceeds policy.

https://fedorahosted.org/freeipa/ticket/2765

When we set a password we also need to make sure krbExtraData is set.
If not kadmin will later complain that the object is corrupted at password
change time.

Ticket: https://fedorahosted.org/freeipa/ticket/2764

This was causing the failure count interval to not be applied so
the failure count was never reset to 0.

https://fedorahosted.org/freeipa/ticket/2540

Some of these are not real defects, because we are guaranteed to have valid
context in some functions, and checks are not necessary.
I added the checks anyway in order to silence Coverity on these issues.

One meleak on error condition was fixed in
daemons/ipa-kdb/ipa_kdb_pwdpolicy.c

Silence errors in ipa-client/ipa-getkeytab.c, the code looks wrong, but it is
actually fine as we count before hand so we never actually use the wrong value
that is computed on the last pass when p == 0

Fixes: https://fedorahosted.org/freeipa/ticket/2488

IPA winsync plugin failed to replicate users when default user group
was non-posix even though User Private Groups (UPG) were enabled
on the server. Both their uidNumber and gidNumber were empty and
they missed essential object classes. When the default user group
was made posix and UPG was disabled it did not set gidNumber to
the default group gidNumber.

This patch improves this behavior to set gidNumber correctly
according to UPG configuration and the default group status
(posix/non-posix). 4 situations can occur, the following list
specifies what value is assigned to user gidNumber:
 1) Default group posix, UPG enabled: gidNumber = UPG gidNumber
 2) Default group posix, UPG disabled: gidNumber = default
    group gidNumber
 3) Default group non-posix, UPG enabled: gidNumber = UPG gidNumber
 4) Default group non-posix, UPG disabled: an error is printed to
    the dirsrv log as the gidNumber cannot be retrieved. User
    is replicated in the same way as before this patch, i.e.
    without essential object classes.

https://fedorahosted.org/freeipa/ticket/2436

We need to check for a matching acl only if one match hasn't already been
found, otherwise results are unpredictable and order dependent.

Fixes: https://fedorahosted.org/freeipa/ticket/2393

Fixes: https://fedorahosted.org/freeipa/ticket/2343