Include autoconf.h (either directly or via proxy) before system
headers, so that feature test macros defined there can affect the
system namespace.  Where include order was changed, eliminate some
redundant or unnecessary includes.

ticket: 7961

Take advantage of the strerror_r portability wrapper to simplify code
using it.  Remove unused macros related to strerror_r in
ldap_service_stash.c and plugins.c.

ticket: 7961

Fix three mismatched constant names, and properly alphabetize and
columnize the lists of definitions.  No functional changes.

Per the ASN.1 definition, the KrbKey salt field is optional.  Since
1.7, we have been treating it as mandatory in the encoder; since 1.11,
we have been treating it as mandatory in the decoder.  Mostly by luck,
we have been encoding a salt type of 0 when key_data_ver is 1, but we
really should not be looking at key_data_type[1] or key_data_length[1]
in this situation.  Treat the salt field as optional in the encoder
and decoder.  Although the previous commit ensures that we continue to
always encode a salt (without any dangerous assumptions about
krb5_key_data constructors), this change will allow us to decode key
data encoded by 1.6 without salt fields.

This also fixes issue #7918, by properly setting key_data_ver to 2 if
a salt type but no salt value is present.  It is difficult to get the
decoder to actually assign 2 to key_data_ver just because the salt
field is there, so take care of that in asn1_decode_sequence_of_keys.

Adjust kdbtest.c to match the new behavior by setting key_data_ver to
2 in both test keys.

ticket: 7919
target_version: 1.12.2
tags: pullup

In the LDAP KDB module, ensure that every krb5_key_data we pass to
asn1_encode_sequence_of_keys includes a salt type, for compatibility
with the decoder in unpatched krb5 1.11 and 1.12.

This is not a behavior change by itself; since 1.7 the encoder has
always included a KrbKey salt field because it erroneously treats that
field as non-optional.  (Luckily, the encoded salt always happens to
have salt type 0 because krb5_key_data constructors start with zeroed
memory.)  The next commit will fix the encoder and decoder to properly
treat the KrbKey salt field as optional, so we need this change to
ensure that our encodings remain compatible.

Also fix the ASN.1 tests to set key_data_ver correctly for the sample
test key data.

ticket: 7919

Replace most calls to krb5_set_error_message with k5_setmsg for
brevity.  Leave alone plugin sources where we don't include k5-int.h
(mostly PKINIT).

The LDAP debug level option (#7551) causes a build failure with the
Solaris LDAP library, which does not have LDAP_OPT_DEBUG_LEVEL.

ticket: 7870 (new)
target_version: 1.12.2
tags: pullup

In krb5_ldap_initialize, don't just blat the LDAP error into the
extended message; give an indication of which LDAP operation we were
trying to do and show what parameters we gave to it.

(Also, krb5_set_error_message can handle a null context argument, so
don't bother to check before calling.)

ticket: 7739 (new)
target_version: 1.12
tags: pullup

When we allocate space for an array of key_data structures, make sure
we allocate at least one, so we don't spuriously fail on platforms
where malloc(0) returns NULL.  Where we use malloc, use k5calloc
instead.  Where we use krb5_db_alloc or realloc, just allocate an
extra entry.