design choices for a loadable module interface

[ghudson@MIT.EDU]

Based on some internal discussions, I think this conversation needs to
be continued slightly and summarized.  To simplify the summary, here
are two concrete ABI design shapes:

1. Plan Nico: each dynamic plugin exports one function symbol per
method.  The names are the same across all plugin implementations of
an interface.

2. Plan Simo: each dynamic plugin exports an init function, whose is
constructed based on the plugin implementation name
(e.g. "db2_kdb_init" for the DB2 KDB module, "ldap_kdb_init" for the
LDAP KDB module).  The init function accepts a version number and
outputs a structure full of function pointers for the methods (aka
vtable).

Some arguments in favor of each shape:

* Plan Nico requires the least amount of code for a dynamic plugin
  implemention.

* Plan Nico allows you to add new methods while retaining
  compatibility with old plugins, as long as the new methods are
  optional.

* Plan Simo potentially requires zero changes to the implementation
  source code to make it built into the consumer rather than
  dynamically loaded.  This is interesting for deployments with
  no-shared-library requirements, and possibly also for portability to
  Windows.

* If there are incompatible changes to a pluggable API across versions
  of Kerberos (not just adding new optional methods), Plan Simo makes
  it possible, though perhaps difficult, to provide a shared object
  which works with multiple Kerberos versions.  This is most
  interesting for the DAL, where we have no stability guarantees and
  know we want to make lots of big changes.

* Plan Simo makes it potentially easier to set breakpoints at specific
  method implementations.  This is a pretty minor point, as there are
  good workarounds.