LU-4209 utils: fix O_TMPFILE/O_LOV_DELAY_CREATE conflict

LU-4209 utils: fix O_TMPFILE/O_LOV_DELAY_CREATE conflict

In kernel 3.11 O_TMPFILE was introduced, but the open flag value
conflicts with the O_LOV_DELAY_CREATE flag 020000000 added to fix
LU-812 in Lustre 2.4.  O_LOV_DELAY_CREATE allows applications
to defer file layout and object creation from open time (the default)
until it can instead be specified by the application using an ioctl.

Instead of trying to find a non-conflicting O_LOV_DELAY_CREATE flag
or define a Lustre-specific flag that isn't of use to most/any other
filesystems, use (O_NOCTTY|FASYNC) as the new value.  These flags
are not meaningful for newly-created regular files and should be
ok since O_LOV_DELAY_CREATE is only meaningful for new files.

I looked into using O_ACCMODE/FMODE_WRITE_IOCTL, which allows calling
ioctl() on the minimally-opened fd and is close to what is needed,
but that doesn't allow specifying the actual read or write mode for
the file, and fcntl(F_SETFL) doesn't allow O_RDONLY/O_WRONLY/O_RDWR
to be set after the file is opened.

For 2.5.1 and later, only check for the 020000000 flag in the kernel
for compatibility with applications compiled against 2.5.0 headers,
since this is needed for SLES11 SP2/SP3 clients on 3.0 kernels.

We will keep the 0100000000 flag in O_LOV_DELAY_CREATE for backward
compatibility until 3.13 is the oldest supported client kernel, but
drop the conflicting __O_TMPFILE value of 02000000 since that will
cause an error when running on 3.11+ kernels.  The 020000000 has only
been used in Lustre 2.4.0-2.4.2 and 2.5.0 and always in conjunction
with 0100000000, so any apps that used O_LOV_DELAY_CREATE directly
instead of calling llapi_file_create*() will still work until Linux
3.13 is used.

Signed-off-by: Andreas Dilger <andreas.dilger@intel.com>
Change-Id: I565f3454616edc60c6acee01034aa5d7733ebbe5
Reviewed-by: Bob Glossman <bob.glossman@intel.com>
Reviewed-by: Peng Tao <bergwolf@gmail.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
Reviewed-on: http://review.whamcloud.com/9492
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>