ctdb-scripts: Support storing statd-callout state in cluster filesystem

ctdb-scripts: Support storing statd-callout state in cluster filesystem

CTDB_STATD_CALLOUT_SHARED_STORAGE is a new configuration variable
indicating where statd-callout should store its NFS client locking
data.  See the update to ctdb-script.options(5) for details.

This adds back functionality that was removed in commit
12cc82623150ca4a83482f1b7165401cbdecd3de.  The commit message doesn't
say why this was changed but it was most likely due to a cluster
filesystem hanging at inopportune times.  Hence, this is re-added as a
non-default option.  There are 2 justifications for re-adding it:

* The existing method (persistent_db) relies on dequeuing data during
  the monitor event, which loses any queued data on node crash.

* NFS-Ganesha writes NFSv4 client locking data to a cluster
  filesystem, by default.  Something similar might as well exist for
  NFSv3.

Note that this could create the files for sm-notify in add-client.
However, this would require an alternate implementation of
send_notifies() (or a change to the implementation for persistent_db
too).  It seems better to leave add-client lightweight and do the work
in notify, since add-client is a more frequent operation.

Unconditionally create the state directory on startup.  This is
currently implicitly created for persistent_db when the queue
directory is created.  However, it isn't created anywhere else for
shared_dir, so do it in a common place.

In test mode, the shared storage location has a prefix added so files
are created within the test environment.

Signed-off-by: Martin Schwenke <mschwenke@ddn.com>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>