Serialization framework future

[ghudson@MIT.EDU]

I'm working on implementing gss_import_cred/gss_export_cred, and for
that I'll need a way to serialize a credential (the TGT credential
from a memory ccache).

This leads me to think about the state of our serialization framework,
which I'm not fond of for a number of reasons: the coding style is
rather divergent from our current practices, it uses krb5_* symbol
names even though it's not part of the public API, and everything goes
through a table lookup of KV5M_* values for no reason (which adds
artificial exception cases for sizing and serializing).

As far as I can see, the only public interfaces to this stuff are the
gss_import/gss_export APIs, so we have a lot of freedom to change
this.  Options I can see for serialization are:

1. Leave it alone (just add a cred serializer without changing
anything about the code).

2. Alter the coding style and symbol names without changing the
design.

3. Rewrite it more aggresively (eliminate the magic number table and
just having size/serialize/unserialize functions for each type).

4. Borrow the krb5_storage framework from Heimdal.

Heimdal's krb5_storage is a readable/writable buffer with a few
different back ends (fixed memory, resizable memory, and file
descriptor; it has an internal vtable with fetch/store/seek/trunc/free
operations), along with some functions for marshalling and
unmarshalling krb5 data types to or from a buffer.  It's maybe a
little over-engineered for this specific purpose, but it could come in
handy for other purposes, and could perhaps replace k5buf and asn1buf
in the future.  We would have to alter the code somewhat to fit, so it
wouldn't be a simple drop-in.

Opinions?