Bug#11765687 (MySQL58677): No privilege on table / view, but can know #rows / underlying table's name

1 - If a user had SHOW VIEW and SELECT privileges on a view and
this view was referencing another view, EXPLAIN SELECT on the outer
view (that the user had privileges on) could reveal the structure
of the underlying "inner" view as well as the number of rows in
the underlying tables, even if the user had privileges on none of
these referenced objects.

This happened because we used DEFINER's UID ("SUID") not just for
the view given in EXPLAIN, but also when checking privileges on
the underlying views (where we should use the UID of the EXPLAIN's
INVOKER instead).

We no longer run the EXPLAIN SUID (with DEFINER's privileges).
This prevents a possible exploit and makes permissions more
orthogonal.

2 - EXPLAIN SELECT would reveal a view's structure even if the user
did not have SHOW VIEW privileges for that view, as long as they
had SELECT privilege on the underlying tables.

Instead of requiring both SHOW VIEW privilege on a view and SELECT
privilege on all underlying tables, we were checking for presence
of either of them.

We now explicitly require SHOW VIEW and SELECT privileges on
the view we run EXPLAIN SELECT on, as well as all its
underlying views. We also require SELECT on all relevant
tables. 


mysql-test/r/view_grant.result:
  add extensive tests to illustrate desired behavior and
  prevent regressions (as always).
mysql-test/t/view_grant.test:
  add extensive tests to illustrate desired behavior and
  prevent regressions (as always).
sql/sql_view.cc:
  We no longer run the EXPLAIN SUID (with DEFINER's privileges).
  To achieve this, we use a temporary, SUID-less TABLE_LIST for
  the views while checking privileges.