locks: Parse lock type earlier

Same reason as for previous patch.

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
locks: Don't dump locks in per-task manner (v3)

We have a problem with file locks (bug #2512) -- the /proc/locks
file shows the ID of lock creator, not the owner. Thus, if the
creator died, but holder is still alive, criu fails to dump the
lock held by latter task.

The proposal is to find who _might_ hold the lock by checking
for dev:inode pairs on lock vs file descriptors being dumped.
If the creator of the lock is still alive, then he will take
the priority.

One thing to note about flocks -- these belong to file entries,
not to tasks. Thus, when we meet one, we should check whether
the flock is really held by task's FD by trying to set yet
another one. In case of success -- lock really belongs to fd
we dump, in case it doesn't trylock should fail.

At the very end -- walk the list of locks and dump them all at
once, which is possible by merge of per-task file-locks images
into one global one.

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
test: Check that shared locks work

Shared here means that a flock is visible from two tasks -- the
owner one and its child.

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
test: Check that inherited flocks work

Inherited flock is the one that a task got from its parent.
In case parent closes the corresponding fd, the /proc/locks
still shows the parent pid, while the lock is owned by child.

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
test: Check that overlapping locks work

If we open a file, lock one, fork, then close and
open the file in parent again, lock should 'slide'
to the child process anyway.

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
test: Check that criu's donwgrading quirk works

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
dump: Don't allocate dfds in case we dump shared fdtable

After patches, that dump locks w/o dfds array, we can even
not allocate one when we don't need it.

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>