illumos gate

Out for review:
http://ma.nexenta.com/gwr/extsec/

Some design notes:

The (in-kernel) smbsrv module, by design, knows very little about authentication.
The smbsrv kmod handles each SMB "session setup" request as follows:
- unwrapping the "security blob",
- write it into the "smbauth" named pipe
- wait for a and read a response "blob"
- send the SMB response with that blob.

All the interesting work happens in the smbd_authsvc. In there, we:
- receive a "security blob" from the kernel module
- unwrap the SPNEGO wrapper,
- figure out what security flavor we're using and pass the unwrapped stuff to one of the "back ends".
- add an SPNEGO wrapper over the response from the "back end" and send that back down the pipe.

Each such conversation happens on a separate pipe instance,
each such instance serviced by a single thread. The smbauth pipe
serializes the the authentication converstaion, which in the smbsrv
kmod is handled by potentially many threads (taskq workers), but in
the smbd_authsvc each conversation is handled in just one thread.

There are three "back end" modules selectable by the SPNEGO
mechanism (sort-of - "raw" NTLMSSP "cheats" here).
1: raw NTLMSSP (NTLMSSP protocol without an SPNEGO wrapper)
2: NTLMSSP (normal NTLMSSP three message exchange)
3: Kerberos (essentially gsssapi)

The Kerberos back-end is the tricky one, as in this back end, we
have to get the authorization information out of the Kerberos ticket
used for authentication. That authorization data is RPC encoded,
carried in a KRB5_AUTHDATA_IF_RELEVANT blob in the ticket.
Some updates in the Kerberos code are required to correctly
dig that authorization data out of the ticket.