Virtual keyspace metadata support immplementation

[tengu-alt]

This PR provides access to the virtual metadata tables exposed through the system_virtual_schema keyspace.

Example query:

cqlsh> SELECT * FROM system_virtual_schema.tables;

 keyspace_name         | table_name                       | comment
-----------------------+----------------------------------+----------------------------------------------------
          system_views |                    batch_metrics |               Metrics specific to batch statements
          system_views |                           caches |                                      system caches
          system_views |    cidr_filtering_metrics_counts |           Count metrics specific to CIDR filtering
          system_views | cidr_filtering_metrics_latencies |         Latency metrics specific to CIDR filtering
          system_views |                          clients |                        currently connected clients 

The system_virtual_schema keyspace contains keyspaces, tables, and columns that users can now parse by specifying a keyspace.

Users can retrieve parsed tables using the VirtualKeyspaceMetadata(keyspace string) method for the Session.

The implementation is based on how the driver retrieves regular keyspace metadata.

[dkropachev]

Can you please fix indent:

Suggested change

	const stmt = `
	SELECT
	table_name,
	comment
	FROM system_virtual_schema.tables
	WHERE keyspace_name = ?`
	const stmt = `
	SELECT
	table_name,
	comment
	FROM system_virtual_schema.tables
	WHERE keyspace_name = ?`

[tengu-alt]

agree, fixed

[dkropachev]

Same ident problem:

Suggested change

	const stmt = `
	SELECT
	table_name,
	column_name,
	clustering_order,
	kind,
	type
	FROM system_virtual_schema.columns
	WHERE keyspace_name = ?`
	const stmt = `
	SELECT
	table_name,
	column_name,
	clustering_order,
	kind,
	type
	FROM system_virtual_schema.columns
	WHERE keyspace_name = ?`

[tengu-alt]

fixed

[dkropachev]

Shouldn't you invalidate it at some point.
Say you upgrade cluster from one version to another, driver will still keep old schema.

Probably on handleNodeUp you could read release_version select release_version from system.local where key = 'local' and invalidate or update cache if it has changed.

Another problem if your cluster half on new version half on another.
Now you depends on where have your control connection landed, if it has landed on a node with new version, session will give you a new schema, while old nodes don't support it.
Way to solve it is to run queries not on control connection, but rather on the node with oldest version available, if you were do so, you can't pick all the nodes from the cluster, you have to adhere to HostSelectionPolicy, say if it is dcAwareRR you will need to filter out all nodes from other datacenters.

[tengu-alt]

I agree with your point about invalidation, but virtual metadata is only requested on the user's purpose, not by some node event, also virtual tables can't be changed, if we talk about some schemaAgreement case. In my opinion, it is unnecessary to invalidate it on every getSchema request, and i think it is unnecessary to remove a control connection, it is good to keep the existing pattern of the metadata requests.

[dkropachev]

If you clear cache a the betting of getSchema it means that there is going to be no cache, why just not drop it.
If you drop the cache then there is no point in having virtualSchemaDescriber, you can just move code to Session.

[tengu-alt]

I totally agree with you, but in my opinion, it is good to keep an existing pattern of processing the metadata (virtual or not)

[dkropachev]

I would recommend, in this particular case, use sync.Map instead of Mutex + map.

[tengu-alt]

I think it is preferable to use mutex, to keep the existing pattern, and avoid unnecessary code complexity.