aufs: copyup supports for a sticky bit of the parent

A new copyup scheme (originally Al Viro's idea) which was introduced
recently contains a problem when the sticky bit of the parent dir on the
branch fs is set.
Since the new copyup scheme calls vfs_rename() internally, the generic
permission check is done in VFS and the sticky bit prohibits the rename
operation when the ownership doesn't match.
Finally the copyup returns an error.
See http://www.mail-archive.com/aufs-users@lists.sourceforge.net/msg04202.html
and its thread in detail.

Generally speaking,
- aufs should respect the native feature (including security) of the
  branch fs as possible.
- as long as the sticky bit is set to the branch, aufs should follow the
  behaviour of the branch fs (which causes an error in this case).
- on the other hand, the copy-up should be done internally and
  transparently (from the users' view). It means aufs should break the
  sticky bit protection.
- actually the old versions of aufs didn't issue the rename operation as
  a part of the copy-up and this problem didn't happen ever.

Honestly speaking, I am not sure this is the right decision. But this
commit is for the case when the sticky bit of the parent dir on the
branch fs is set.

Reported-by: Francois Goudal <fg@satcom1.com>
Reported-by: Justin <jlec@gentoo.org>
Reported-by: Klaus Knopper <aufs@knopper.net>
Signed-off-by: J. R. Okajima <hooanon05@yahoo.co.jp>
Merge branch 'aufs3.2/00base' into aufs3.2.x/00base
Merge remote branch 'aufs3-standalone/aufs3.2/00base' into aufs3.2/10static
Merge branch 'aufs3.2/10static' into aufs3.2/11proc_map
Merge branch 'aufs3.2/10static' into aufs3.2.x/10static
Merge remote branch 'aufs3-standalone/aufs3.2.x/00base' into aufs3.2.x/10static
Merge branch 'aufs3.2/11proc_map' into aufs3.2.x/11proc_map
Merge branch 'aufs3.2.x/10static' into aufs3.2.x/11proc_map