LU-17308 mgs: move pool_cmd check to the kernel

LU-17308 mgs: move pool_cmd check to the kernel

Several checks for pool_cmd need to be done before touching the MGS
configuration.

e.g: the following case should be denied before adding a destroy
record in the MGS configurations:
 - The pool does not exist
 - The pool is not empty (OSTs still in the pool)

This work is done in userspace (check_pool_cmd) by checking the client
lov parameters for pools. But nothing guarantees those parameters to
be in sync. So, only the MGS configuration should be trusted for that.

This patch move those checks in the kernel. There are several reasons
for this:
 - It guarantees the pool configurations consistency even if an
   external tool is used.
 - For standalone MGS, it limits the overhead of reading the
   configuration several times.

This patch add a "-n|--nowait" option for pool_cmd to skip waiting
for pool updates on the clients. This is useful when doing a lot of
pool_cmd in a raw. And this avoids cancelling clients CONFIG lock
each times (because of mgc_requeue_timeout_min).

e.g:
  lctl pool_destroy -n lustre.old
  lctl pool_new -n lustre.test
  lctl pool_add -n lustre.test OST0001
  ...
  lctl pool_add lustre.test OST0010

check_pool_cmd_result() is modified to compute the client wait delay
with mgc_requeue_timeout_min.

Add a regression test "ost-pools 2f".

Test-Parameters: testlist=ost-pools
Test-Parameters: testlist=ost-pools
Test-Parameters: testlist=ost-pools env=ONLY=2f,ONLY_REPEAT=50
Test-Parameters: testlist=ost-pools env=ONLY=2f,ONLY_REPEAT=50
Signed-off-by: Etienne AUJAMES <eaujames@ddn.com>
Change-Id: Ifbc49b5667bf17253716052a7480114936c65149
Reviewed-on: https://review.whamcloud.com/c/fs/lustre-release/+/53202
Tested-by: jenkins <devops@whamcloud.com>
Tested-by: Maloo <maloo@whamcloud.com>
Reviewed-by: Guillaume Courrier <guillaume.courrier@cea.fr>
Reviewed-by: Andreas Dilger <adilger@whamcloud.com>
Reviewed-by: James Simmons <jsimmons@infradead.org>
Reviewed-by: Oleg Drokin <green@whamcloud.com>