Snapshot jmx mbeans name collision on 2nd parallel snapshot [DBZ-2295]

Migrated from [DBZ-2295](https://issues.redhat.com/browse/DBZ-2295)

I've noticed that snapshot JMX Mbeans cannot be re-registered for tracking progress of a _second_ successive parallel snapshot. This means for a second update to the table-whitelist, there is no way to view its progress as the JMX metrics continue to show the previous parallel snapshot.

 
{code:java}
WARN   MySQL|test|task  Error while register the MBean 'debezium.mysql:type=connector-metrics,context=oldBinlog,server=test': debezium.mysql:type=connector-metrics,context=oldBinlog,server=test   [io.debezium.connector.mysql.BinlogReader]
WARN   MySQL|test|task  Error while register the MBean 'debezium.mysql:type=connector-metrics,context=snapshot,server=test': debezium.mysql:type=connector-metrics,context=snapshot,server=test   [io.debezium.connector.mysql.SnapshotReader]
WARN   MySQL|test|task  Error while register the MBean 'debezium.mysql:type=connector-metrics,context=newBinlog,server=test': debezium.mysql:type=connector-metrics,context=newBinlog,server=test   [io.debezium.connector.mysql.BinlogReader]{code}
 

DBZ-640 made the move to not unregister the snapshot MBeans immediately after completion (which definitely makes sense), however I'm not sure then how I can force the mbeans to be unregistered before my second parallel snapshot short of restarting the entire connect instance.

Restarting the connector and/or its tasks before updating the table-whitelist again does not seem to unregister the Mbeans since the ChainedReader's {{destroy()}} method  only propagates to current and/or remaining readers so I don't see a feasible way of  reaching a completed SnapshotReader's {{destroy()}} method which would unregister the Mbeans, so I could re-parallel snapshot without name collisions. 

Start by tracing ChainedReader.destroy() and the completed SnapshotReader lifecycle, then inspect the MBean registration paths shown in BinlogReader and SnapshotReader. Verify the behavior with two successive parallel snapshots after changing the table-whitelist; done means the second snapshot can register its snapshot, oldBinlog, and newBinlog MBeans without name collisions.

Written by the indexing model from the issue text.