kdb ldap back end

[Ken Raeburn]

I'm (finally!) getting a chance to start digging into the LDAP back  
end.  One issue has jumped out at me:  On some systems, dynamically  
loadable objects and shared libraries are not the same.  So for  
portability, we'll assume the system can support loading an object  
with dlopen (or other system-specific means), or linking against it  
as a shared library, but not both.

The ldap-util program links against the ldap database plugin,  
currently.  I think the best fix is probably to split off most of the  
plugin into a separate shared library that both the ldap-util program  
and the database plugin are linked against.  But that brings up the  
question of how much should move and how much stay in the plugin, and  
what should be exported from the new library.  (Are we ready to  
consider it a published interface that we'll maintain binary  
compatibility with going forward?  My guess is no, so we can do  
whatever we want now and change it as needed later.)

The alternative approach is probably to have the ldap-util program  
dlopen the database module and go looking for the functions it wants  
to call; I don't like that approach as much, myself, though it does  
let us sidestep the shared-library questions for now.

Comments?

Ken