io_u: Fix bad interaction with --openfiles and non-sequential file selection policy

io_u: Fix bad interaction with --openfiles and non-sequential file selection policy

Problem happens when --openfiles is set and file_service_type != FIO_FSERVICE_SEQ.
In function __get_next_file, we decrement file_service_left and if 0, we select
next file to operate on.
However, get_next_file_rand can return -EBUSY if too many files are already opened,
and __get_next_file exits with error.

In next invocation of __get_next_file, we decrement file_service_left again (from 0),
wrapping around to 2^32-1, effectively locking __get_next_file to always select the same.

Algorithm to observe bad behavior:
fio --randseed=1 --ioengine=libaio --rw=randwrite --nrfiles=256 --bs=4k --size=256m \
--loops=50 --allow_file_create=1 --write_iolog=log.txt --file_service_type=normal:20 \
--filename_format=object.\$filenum --name=x --openfiles=100

cat log.txt |grep write |cut -f 1 -d " " |sort |uniq -c | sort -n | sed "s/[.]/ /" \
| while read a b c; do echo $c $b $a; done |sort -n
....
70 object 17
71 object 19
72 object 22
73 object 65296
74 object 65255
75 object 33
76 object 27
77 object 25
78 object 65243
79 object 36
80 object 49
81 object 47
....

Signed-off-by: Adam Kupczyk <akupczyk@redhat.com>