LU-17190 llite: release locks after all read-head pages submit

LU-17190 llite: release locks after all read-head pages submit

We put all acquired DLM extent locks for read-ahead in a list.
After all read-ahead pages are submitted, then the client releases
all DLM extent locks acquired during the previous read-ahead.

By this way, in a extent lock blocking AST, all reading extents
have already submitted and put into the list @oo_reading_exts of
the OSC object. Then the client can check this list to find out
the conflict outstanding extents as all I/O RPC slots (limited by
osc.*.max_rpcs_in_flight) are used out by direct I/Os which take
server-side locking.

Otherwise, in the original way, it matches DLM extent lock, adds
read-ahead pages into queue list, releases the previous matched
lock; repeat this progress for read-ahead and finally submit the
I/O containing all read-ahead pages (@osc_io_submit). The conflict
extents in OES_LOCK_DONE state may be added into the list
@oo_reading_exts after the check in blocking AST.
On the client side in the blocking AST from server-side locking
for DIO it will try to lock the pages in these lockdone extents
to writeback or discard these cached pages covered by the lock;
All pages in lockdone extent are locked (PG_locked), and these
extents are waiting for RPC slots while all RPC slots are used
out by DIO.
Thus it may cause deadlock.

This patch can be used by the next patch about high priority I/O
for blocking AST. The client can check the list @oo_reading_exts
to find out the conflict outstanding extents. Put these conflict
extents into HP list, thus they can be sent to OSTs and handled
ASAP, avoiding the possible deadlock.

Change-Id: I5661607ecba3b6cbd6e29ae3fa14566a5ec045f1
Signed-off-by: Qian Yingjin <qian@ddn.com>
Reviewed-on: https://review.whamcloud.com/c/fs/lustre-release/+/56324
Tested-by: jenkins <devops@whamcloud.com>
Tested-by: Maloo <maloo@whamcloud.com>
Reviewed-by: Patrick Farrell <pfarrell@whamcloud.com>
Reviewed-by: Shaun Tancheff <shaun.tancheff@hpe.com>
Reviewed-by: Oleg Drokin <green@whamcloud.com>