The problem was that LOCK TABLES statement on a view did insufficient
privilege checking for view's underlying tables.

This patch solves the problem by ensuring that when we lock tables
through a view we require the same SELECT and LOCK TABLES privileges
on its underlying tables as would have been required if these tables
were locked directly.

To avoid breaking mysqldump/pump tools which need to be able to dump
views with broken definer, which in default mode involves locking of
such views, we accept both cases when:
1) User whose context will be used for view execution has necessary
   privileges on underlying tables.
2) User who originally inititated LOCK TABLES operation has them
   (which is typically for admin/backup users used for dumping).

This is version of the patch for 5.6 branch.

Reviewed-by: Sivert Sorumgaard <sivert.sorumgaard@oracle.com>
Reviewed-by: Gopal Shankar <gopal.shankar@oracle.com>