Fix GSS krb5 initial sequence number gap handling

Since #2040, the dummy queue element inserted by g_order_init no
longer compares less than the initial sequence number, so we fail when
the first few sequence numbers are received out of order.  Properly
detect when a sequence number fits between the dummy element and the
first real queue element.

[ghudson@mit.edu: rewrote commit message]

ticket: 7872
target_version: 1.12.2
tags: pullup
Add tests for GSSAPI sequence number processing

ticket: 7872
Improve internal API for GSS sequence numbers

Use an opaque structure type instead of a void pointer for the
sequence number state.  Rename all functions to use a g_seqstate
prefix rather than a mix of g_order and g_queue.  Remove the
unneccessary indirection from the state object parameter in
g_seqstate_check and g_seqstate_free.  Return OM_uint32 where we
return a GSS major code, long where we return an errno value, and void
where we can't fail.
Rewrite GSS sequence state tracking code

Replace util_ordering.c with a new file util_seqstate.c, implemented
using a bitmap of previously received sequence numbers instead of a
20-element circular queue.  This approach has slightly different
limitations--it can check for replays for values within 64 of the
expected next number, where the old code could check within the range
of the last 20 received numbers regardless of how far apart they are.
The new approach should work as well or better for any realistic
packet reordering scenario.

ticket: 7879 (new)