Add support for session-based workers

Session-based workers (as opposed to stateless workers) require additional lifecycle functionality that Remus is in a position to provide.

Worker startup

Session-based workers often need more intricate configuration at startup. Examples: solid modeling kernels may enable/disable journaling, set up memory limits, file quotas. Workers may need access to this configuration information at various points in their lifecycle.

It is possible that some workers might be virtual machines that should be started on demand.
Some configuration may be through environment variables (e.g., OpenCascade requires DYLD_FALLBACK_LIBRARY_PATH to be set in order for SMTK to run).
Some configuration must be done after process startup but before the session is initiated (e.g., Capstone requires a default modeling kernel to be selected before a file is loaded or any model operation is invoked).
Some configuration information may be required after session initiation, such as paths where model reads/writes are allowed.

Remus RW files should accept the following tags and force the WorkerFactory (or potentially subclasses) to deal with them:

Tag. In addition to File and FileFormat, JobRequirements also contain a tag that session-based workers use to enumerate and describe resources. Either the tag string could be stored directory or a TagFile directive might allow it to be separate.
Environment. This should be a dictionary of environment variable names and values to set before spawning a worker as a separate process.
Arguments. Beside passing the Remus server host and port on the command line, it should be possible to pass additional configuration information to the worker.
Session resource enumeration

SMTK is currently using the worker tag to store information about resources available to workers so that user interfaces may present it, since it can affect the choice of otherwise-identical workers. Currently there are 2 major resources being enumerated by SMTK in the JobRequirements tag. The first is a "site" identifier, specified by the system administrator, indicating the filesystem available to hold models. A single site may span multiple hosts (using NFS filesystems) and a single host may provide multiple sites (different top-level directories).

The second resource that the tag enumerates is the list of solid modeling kernels a worker provides. The list of file types that each modeling kernel supports is bundled with each modeling kernel entry. Often sessions must be initialized to default to one kernel or another; sometimes kernels provided by the same binary are mutually exclusive to one another within the same process.

One can imagine Remus providing support for clients to discover information about directories and files accessible to a worker (with no or very little cooperation required by the worker). However, this could lead to security issues if the worker is not given a chance to set a policy. At some point SMTK will need to provide file browser functionality for remote model workers and it might be useful for meshes as well (especially if a model is to be created from a very large mesh that cannot be moved from the host where it was created).

Resource transport

Although not currently a concern for SMTK, the permanent transfer of files to and from workers may also be useful at some point (as opposed to the job-based transfer of input and output files).

Preemption

When a worker represents a session it is highly desirable for the client to have the ability to supercede a job with another. For instance, if a mesh worker is session based, the client may wish to cancel a mesh in progress as soon as the user updates a meshing parameter; the same worker should replace its current job submission with the client's modified job submission and restart processing.

Kitware / Remus