information_schema should be handled by the engine fully

[findepi]

Using example from #900 we see that eg SQLServer's information_schema leaks out

SELECT (correctly) returns from internal information_schema.columns

presto> SELECT * FROM sqlserver.information_schema.columns;
 table_catalog | table_schema |        table_name        | column_name | ordinal_position | column_default | is_nullable |  data_type   | comment | extra_info
---------------+--------------+--------------------------+-------------+------------------+----------------+-------------+--------------+---------+------------
 sqlserver     | sys          | service_broker_endpoints | name        |                1 | NULL           | YES         | varchar(128) | NULL    | NULL
...

... but DESCRIBE shows columns from SQLServer's information_schema.columns

presto> DESCRIBE sqlserver.information_schema.columns;
          Column          |     Type      | Extra | Comment
--------------------------+---------------+-------+---------
 table_catalog            | varchar(128)  |       |
 table_schema             | varchar(128)  |       |
 table_name               | varchar(128)  |       |
 column_name              | varchar(128)  |       |
 ordinal_position         | integer       |       |
 column_default           | varchar(4000) |       |
 is_nullable              | varchar(3)    |       |
 data_type                | varchar(128)  |       |
 character_maximum_length | integer       |       |
 character_octet_length   | integer       |       |
 numeric_precision        | tinyint       |       |
 numeric_precision_radix  | smallint      |       |
 numeric_scale            | integer       |       |
 datetime_precision       | smallint      |       |
 character_set_catalog    | varchar(128)  |       |
 character_set_schema     | varchar(128)  |       |
 character_set_name       | varchar(128)  |       |
 collation_catalog        | varchar(128)  |       |
 collation_schema         | varchar(128)  |       |
 collation_name           | varchar(128)  |       |
 domain_catalog           | varchar(128)  |       |
 domain_schema            | varchar(128)  |       |
 domain_name              | varchar(128)  |       |
(23 rows)

[findepi]

Today information_schema needs to be filtered out by each connector individually.

E.g. It is explicitly filtered out here:
https://github.com/prestosql/presto/blob/3536c7da8fe2f4e1bd4954edaeb7cb22029d7316/presto-base-jdbc/src/main/java/io/prestosql/plugin/jdbc/BaseJdbcClient.java#L177
https://github.com/prestosql/presto/blob/85659a03d52fab6c94d771b2d75856d4acc3be4e/presto-mysql/src/main/java/io/prestosql/plugin/mysql/MySqlClient.java#L135
https://github.com/prestosql/presto/blob/83235e86ee57a0ede5b65b509d167de4d2ebd3fe/presto-phoenix/src/main/java/io/prestosql/plugin/phoenix/PhoenixClient.java#L201

Of course, this is error-prone, I witnessed that when working on #1218.
Under that issue, I'm not changing this, just fixing Hive connector,
but I think we should handle everything information_schema-related
outside of the connector, because this schema is handled outside of it.

[findepi]

@martint or, is our intention to let connector provide additional tables within information_schema schema?

[haldes]

@findepi
Adding another few instance

https://github.com/prestosql/presto/blob/a7a2d7c441d1ed6565c6902425bfbd1a56b74c40/presto-plugin-toolkit/src/main/java/io/prestosql/plugin/base/security/FileBasedAccessControl.java#L402

https://github.com/prestosql/presto/blob/a7a2d7c441d1ed6565c6902425bfbd1a56b74c40/presto-plugin-toolkit/src/main/java/io/prestosql/plugin/base/security/FileBasedSystemAccessControl.java#L703