a new lock type

[ymatsuda]

This PR introduces the third type of lock, the APPEND lock. (I'd like to solicit a better name!)
It doesn't check the lock high-water mark for the lock compatibility, but it always updates the lock high-water mark. Here is the summary of three lock types.

WRITE => checks the lock high-water mark and updates the lock high-water mark
READ => checks the lock high-water mark but doesn't update the lock high-water mark
APPEND => doesn't check the lock high-water mark but always updates the lock high-water mark

APPEND lock alone may not seem so useful. It is meant to be used with other locks.

Suppose you have a hierarchical resource (parent/child). You want to update the child resource in rapid succession, and you don't want other processes to update the child while doing it. Using a write lock on the parent for every child update is inefficient. It causes self-imposed lock contentions. One solution is to mark the parent resource with the ownership. It tells who is owning the resource. This transaction uses a write lock. A child update transaction uses a read lock to ensure that the current process still owns the resource. It will fail when the ownership is taken by another process.

This seems to work. But there is a potential issue. There is no way for the new owner to ensure that the child update is not in-flight when taking the ownership. The new owner may commit a transaction changing the ownership before a child update become visible to it.

An APPEND lock can be used when this is a concern. The ownership change transaction takes WRITE locks on the parent resource and the child resource. The child update transaction takes a READ lock on the parent and an APPEND lock on the child. This ensures that child updates are not causing lock contentions, and there is no in-flight transactions when the ownership changes.

[biplap-sarkar]

Can't think of a better lock name, unfortunately. One potential name might be secondary lock to put more emphasis on the fact that this can't be used as one of the primary locking mechanisms but that may sound too generic.

[criccomini]

Nit: somewhat subtle that readLocks doesn't need to be marked but appendLocks does. perhaps worth a comment.