On 32-bit platforms, the code to translate an iteration count of 0 to
2^32 can trigger a compiler warning.  Since we will basically never
accept an iteration count that high (right now we reject anything
above 2^24), just reject it out of hand.

Also add a testing interface to allow weak iteration counts.
(Published test vectors use weak iteration counts.)

ticket: 7465
target_version: 1.12
tags: pullup

Wherever we use k5alloc with a multiplication in the size parameter,,
use the new k5calloc helper function instead.

Expand the concept of an IOV block state into a cursor which remembers
the IOV set being iterated over, the block size, and both input and
output positions.  Eliminate the no-copy inline block getter for now,
but provide helpers to grab contiguous chains of blocks from a cursor.
Also provide an inline helper to sum the total length of an iov chain.

Provide default values in pre.in for PROG_LIBPATH, PROG_RPATH,
SHLIB_DIRS, SHLIB_RDIRS, and STOBJLISTS so that they don't have to be
specified in the common case.  Rename KRB5_RUN_ENV and KRB5_RUN_VARS
to RUN_SETUP (already the most commonly used name) and RUN_VARS.  Make
sure to use DEFINES for local defines (not DEFS).  Remove some other
unnecessary makefile content.

Locking and unlocking a non-recursive mutex is a simple memory
operation and should not fail on any reasonable platform with correct
usage.  A pthread mutex can return EDEADLK on lock or EPERM on unlock,
or EINVAL if the mutex is uninitialized, but all of these conditions
would reflect serious bugs in the calling code.

Change the k5_mutex_lock and k5_mutex_unlock wrappers to return void
and adjust all call sites.  Propagate this change through
k5_cc_mutex_lock and k5_cc_mutex_unlock as well.

ticket: 7628

By a strict reading of the C standard, memcpy and memcmp have
undefined behavior if their pointer arguments aren't valid object
pointers, even if the length argument is 0.  Compilers are becoming
more aggressive about breaking code with undefined behavior, so we
should try to avoid it when possible.

In a krb5_data object, we frequently use NULL as the data value when
the length is 0.  Accordingly, we should avoid copying from or
comparing the data field of a length-0 krb5_data object.  Add checks
to our wrapper functions (like data_eq and k5_memdup) and to code
which works with possibly-empty krb5_data objects.  In a few places,
use wrapper functions to simplify the code rather than adding checks.