[krbdev.mit.edu #8352] Year 2038 fixes

[Greg Hudson via RT]

In January 2038, the Unix time value overflows signed 32-bit integers, 
which will break a wide variety of krb5 operations.  This problem can 
already be observed by trying to set a very long expiration time for a 
principal (modprinc -pwexpire "25 years" princname).

On platforms with 32-bit time_t, this problem is essentially 
intractable; we would have to avoid all platform functions using time_t 
and find some other way of obtaining the current time.  Also, even if 
krb5 continued working after 2038 on such systems, the remainder of the 
operating system would not.  So our solution can be predicated on 64-
bit time_t.

On platforms with 64-bit time_t, we continue to have many issues 
because krb5_timestamp is fixed at 32 bits.  This type appears in 
numerous libkrb5 APIs and public structures, in protocols such as 
kadmin and iprop, and in file formats such as the db2 KDB module.  
Migrating to a 64-bit krb5_timestamp would require a huge transition.

A less difficult option is to use the sign bit of krb5_timestamp to 
represent time values up to year 2106.  The value -1 can remain as a 
distinguished value.  To do this we will need to:

* Create libkrb5 API functions to convert krb5_timestamp to time_t and 
vice versa.

* Scour the code base for uses of krb5_timestamp values, and use the 
conversion functions wherever they are needed.

* Make sure that negative values of krb5_timestamp can be encoded and 
decoded wherever they appear in protocol and file formats.

We also need to consider places in the code which subtract one 
krb5_timestamp value from another (such as when checking clock skew), 
if one of the values can legitimately be negative.