Attached two files, mdev6382_before.test and mdev6382_after.test.

It's exactly the same test, only the 'before' variant is adjusted to pass on the current 10.1 tree, while in the 'after' variant all adjustments related to MDEV-6382 have been removed, it's expected to pass after MDEV-6382 is implemented (unless I made some typos in there).

There are more adjustments in the test to work around unrelated legacy bugs; the are commented with the corresponding JIRA numbers, search or grep for 'MDEV' to find all of them.

The test is lengthy line-wise, but it's very cheap time-wise, even under valgrind, so I didn't feel the urge to optimize the number of statements in there.

Here is what the test does:
it uses a structure of base table -> inner view -> outer view.
It also uses a separate table for multi-table update, insert .. select and such. For this separate table, SELECT privilege is granted in all subtests.
It grants full access to two of the three objects, and applies different privileges to the third object. For each variant, it executes

INSERT ... VALUES
INESRT .. SELECT
REPLACE .. VALUES
REPLACE .. SELECT
UPDATE .. SET column = constant
UPDATE .. SET column = f(column)
multi-table UPDATE (one table updated) with conditions
DELETE
DELETE .. WHERE column = constant
multi-table DELETE without conditions
multi-table DELETE with condition
SELECT *
SELECT * WHERE column = constant
SELECT * WHERE column IN ( subquery )

and EXPLAIN and ANALYZE for each query.

The goal is to check that ANALYZE cannot be executed when either the query or EXPLAIN cannot.
In some questions, the current behavior is obscure, but unless it clearly violates something, it is considered the expected behavior.

The variations of grants used in the test are only a tiny share of the entire pool of possible combinations, and is by no means 100% coverage, but it should present the most basic cases.