Inode cache - setup default values at build time

Restore default parameters settings - they used to be set at run time
in nfs_init. nfs_init has been convered to build-time parameter
initialisation and initialisation of cache inode parameters has been
lost.

Signed-off-by: Max Matveev <makc@gmx.co.uk>
PROXY FSAL - respect array boundaries in bitmap4

Fallout from merging new API and the rest of the code.

Signed-off-by: Max Matveev <makc@gmx.co.uk>
PROXY FSAL - restore support for 'mapped' handles

NFSv4 handle can be up-to 128 bytes long which is not going
to fit into NFSv3, let alone NFSv2, handle. Before 'New Handle'
era Proxy has had support for 'mapping' long NFSv4 handles to shorter
handles which can be used with NFSv2 and NFSv3, 'New Handle' made
this trick impossible. Now with New API we can do it again: use
16 bytes for encode fileid and hash of the NFSv4 handle and give it
to callers who ask for NFSv2 or NFSv3 digest. First 2 bytes of the
'mapped' handle are used to disambiguate it from full NFSv4 handle.

On the database side the mapping is from object+hash to the full
NFSv4 handle from the backend server. Because NFSv4 handle is
variable in length extra care is needed then loading those handles
from the database.

Also there is no more libhandle_mapping - the code is linked into
the single libfsalproxy DSO. Dependency on sqlite3 is on the libfsalproxy,
not on the target ganesha binary.

Signed-off-by: Max Matveev <makc@gmx.co.uk>
PROXY FSAL - don't leak memory for fattr4

Callers for nfs4_FSALattrs_To_Fattr must make sure that
they free the memory allocated inside.

Signed-off-by: Max Matveev <makc@gmx.co.uk>
PROXY FSAL - use single socket to talk to backend

Instead of single RPC client shared across all threads or per-worker
RPC client as it was done in the previous implementation of Proxy's RPC
communication use single socket which can be used to talk to the backend
NFSv4 server.

There is a thread which deals with maintaining the connection, reading
replies from the socket and matching them to the XIDs which had been
sent out.

Each NFS worker thread which sends data out needs to get a 'context'
which contains buffers to encode/decode data from plus some locks and
conditional variables to wait on.  There is a fixed number of those
contexts and it is used for both controlling number of concurrent
requests to the backend and to avoid constant churn of creating and
destroying mutexes.

The 'sending' thread 'donates' a buffer which is used by the receiving
thread to dump reply data into when receiver finds an XID match. The
decoding of the reply is done by the sending thread, not the receiver.

The old 'client id renewer' thread uses the same mechanism to talk
to backend NFS server.

This change removes support for UDP.

Signed-off-by: Max Matveev <makc@gmx.co.uk>
PROXY FSAL - use max_FS_calls to control concurrency

max_FS_calls is meant to control number of concurrent
calls to the filesystem. For Proxy 'filesystem' is the
backend NFS server, if we use max_FS_calls to control
number of pre-created RPC io contexts then it would be
fulfiling the role it was meant to do.

The default number of concurrent RPC contexts is
set to 16.

Signed-off-by: Max Matveev <makc@gmx.co.uk>
PROXY FSAL - use IP address in client ID

When negotiating client IDs with the backend NFSv4 server
include IP address in the client name: a server can assume
that if the client name is the same from two clients then
its the same client trying to reconnect after crash. This results
in the client id ping-pong when two clients on two different hosts
just happen to get the same process ID.

Signed-off-by: Max Matveev <makc@gmx.co.uk>
Fix missing include when enabling NLM

Signed-off-by: Jim Lieb <jlieb@panasas.com>
Suppress strict compile error for unused var.

This adds useless code but maybe rok4 should/will be used
someday?

Signed-off-by: Jim Lieb <jlieb@panasas.com>
Build multiple FSALs at the same time

Replace -with-fsal=XXX configure option with multiple --enable-fsal-XXX
or --disable-fsal-XXX depending on whatever FSAL is considered to be
'common' or 'exotic'. By default all 'common' FSALs will be built unless
explictly disabled with -disable-fsal-XXX and all 'exotic' FSALs will not
be built unless explicitly enabled with --enable-fsal-XXX.

Because multiple FSALs can be in use at any given time the old FS_NAME
does not make sense anymore - it has been mostly retired: it is still used
in the packaging scripts which need more work.

Signed-off-by: Max Matveev <makc@gmx.co.uk>
Client id params got lost between rc9 and new api

restored in struct initializer bits that were in the init code.

Signed-off-by: Jim Lieb <jlieb@panasas.com>