If audit logging is turned off, no attempt will be made for new jobs to log
an audit record, neither to the database nor to the filesystem as a fallback
record.

However, we try initialize the filesystem persistence unit, and if the
fallbackStorageDirectorypoints to a non-readable or non-writable directory
then we log an error.
Also: We schedule periodic uploads of records from the
fallbackStorageDirectory into the database.

If everything is configured ok, this will not cause anything bad, but for
existing fallback recordsperiodic attempts will be made to upload them into
the db, and if the fallbackStorageDirectory pointsto an invalid location
there will be periodic error messages, although audit logging is turned off.

The on/off switch must work better:
No audit-related actions must be performed if auditing is turned off,
except for reading the audit configuration at container startup time. 

Why didn't this show up?
1. There was no test for this case.
2. By default the fallbackStorageDirectory points to 
   $GLOBUS_LOCATION/share/gram-service and I assumed this is always owned
   by the user who runs the container.
   If this is the case things work silently, and for new jobs no auditing
   is performed.

(This doesn't have impact on success/failure of job submission in general)

ToDo:
1. Fix this.
2. Add testcases for this to the audit unit tests.
3. Document that the fallbackStorageDirectory must be readable and writable
   for the account that runs the container.