Commit d5bb7e97 started to preserve the dumpable flag across migration by
using prctl to get the value on dump and set it back on restore.

On some situations, the dumpable flag can be set to 2.  This happens when it is
not reset (with prctl) after using setuid() or after using execv() on a binary
that has executable but not read permissions, when the fs.suid_dumpable sysctl
is also set to 2.  However, it is not possible to set it to 2 using prctl,
which would make criu restore fail.

Fix this by checking for the value before passing it to prctl.  In case the
value of the dumpable flag was 2 at the source, check whether it is already 2
at the destination, which is likely to happen if the fs.suid_dumpable sysctl is
also set to 2 where restore is running.  In that case, preserve the value,
otherwise reset it to 0 which is the most secure fallback.

Fixes: d5bb7e97

Tested:
- Using dumpable02 zdtm test after setting fs.suid_dumpable to 2.
  # sysctl -w fs.suid_dumpable=2
  # test/zdtm.sh ns/static/dumpable02
  4: DEBUG: before dump: dumpable=2
  4: DEBUG: after restore: dumpable=2
  4: PASS
  Test: zdtm/live/static/dumpable02, Result: PASS
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
Acked-by: Andrew Vagin <avagin@parallels.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>