Update tablets invalidation logic

[dkropachev]

Invalidation on events

• On SCHEMA_CHANGE, for target keyspace + table, for all change types: UPDATED or DROPPED drop related tablet records.
• On TOPOLOGY_CHANGE, for REMOVED_NODE (and probably MOVED_NODE) change type, all tablet records that contains this node, to be removed.

Possible optimizations:

• On SCHEMA_CHANGE change types: UPDATED driver can look at what have changed and if nothing that can trigger tablet migration (say, ks replication factor and tablet feature on the table) is touched, then invalidation to be voided

Invalidation on control connection reconnect

When cc is lost, driver can miss some of the events.
So we need some logic to catch up:

• Read keyspace and table descriptions to find if any keyspace or table was removed or updated, doing exactly the same what should be done for SCHEMA_CHANGE event.
• Read system.peers to find if any node was removed and do the same what should be done for TOPOLOGY_CHANGE event.

[Lorak-mmk]

Note: the only thing that is not already handle is updating (not dropping!) keyspace / table (SCHEMA_CHANGE UPDATED event).