Locking mechanism cannot handle initial USER-WRITE=false.

[jamoore]

Ref #337.

If a user attempts to save an entity which:

1. has its USER-WRITE permissions turned off
2. will be locked immediately (i.e. is a part of a graph)

Then the backend will throw the following:

FAILED: test_HandlesPermissionReduction
ome.conditions.SecurityViolation: Updating Project:Id_4264 not allowed.
	at ome.security.BasicSecuritySystem.throwUpdateViolation(BasicSecuritySystem.java:322)
	at ome.security.ACLEventListener.onPreUpdate(ACLEventListener.java:156)

because during merge it has its write permissions (legally) reduced, and during flush, FlushEntityEventListener sets the LOCK flag, which violates the "no write" permissions.

[jmoore]

r923 has the failing test. We'll need a similar test from the client side which attempts the same thing with a umask.

[jmoore]

Though it seems weird, this should probably be something we accept as long as we're going for unix-like functionality. The following is valid:

 $ umask 222
 $ echo test >> new_file
 $ cat new_file
test
 $ echo test2 >> new_file
bash: new_file: Permission denied

[jmoore]

Test now passing. Fixes for #337 fulfilled this requirement. Also related to #345 and the check in ACLEventListener (r928).