Invalidate tablets data

[sylwiaszunejko]

Add tablets invalidation in case node is removed or keyspace/table is dropped/updated.

Fixes: #350

[sylwiaszunejko]

I am still thinking about how to invalidate tablets in case of lost cc in terms of dropped keyspaces/tables. Right now we don't really do whole schema fetch. We only refresh particular keyspace when we try to get the metadata and there is none for that keyspace

gocql/metadata_scylla.go

Lines 266 to 282 in 77bae76

	func (s *schemaDescriber) getSchema(keyspaceName string) (*KeyspaceMetadata, error) {
	s.mu.Lock()
	defer s.mu.Unlock()
	metadata, found := s.cache[keyspaceName]
	if !found {
	// refresh the cache for this keyspace
	err := s.refreshSchema(keyspaceName)
	if err != nil {
	return nil, err
	}
	metadata = s.cache[keyspaceName]
	}
	return metadata, nil
	}

. So should we clear metadata and try to refresh it for every keyspace present in old metadata in case of lost cc? That way we can check if some keyspace/table was dropped, but this is a whole new logic to add so I would like to first ask about second opinion @dkropachev

[dkropachev]

I am still thinking about how to invalidate tablets in case of lost cc in terms of dropped keyspaces/tables. Right now we don't really do whole schema fetch. We only refresh particular keyspace when we try to get the metadata and there is none for that keyspace

gocql/metadata_scylla.go

Lines 266 to 282 in 77bae76

	func (s *schemaDescriber) getSchema(keyspaceName string) (*KeyspaceMetadata, error) {
	s.mu.Lock()
	defer s.mu.Unlock()
	metadata, found := s.cache[keyspaceName]
	if !found {
	// refresh the cache for this keyspace
	err := s.refreshSchema(keyspaceName)
	if err != nil {
	return nil, err
	}
	metadata = s.cache[keyspaceName]
	}
	return metadata, nil
	}

. So should we clear metadata and try to refresh it for every keyspace present in old metadata in case of lost cc? That way we can check if some keyspace/table was dropped, but this is a whole new logic to add so I would like to first ask about second opinion @dkropachev

let's address it in a separate PR.