Schema recovery should be atomic operation

Unfortunate timing can cause corrupted schema history topic during schema recovery operation. That corruption can be minor and only detected hours later when suddenly debezium encounters data change event for table not found in recovered schema.

To make it more robust could schema recovery detect the last attempt was not properly finished and either fail task or automatically start the recovery again from beginning.

Steps to reproduce:
1. have running connector, have large amount schemas in db.
2. update job config, change the history topic to some new topic, change snapshot.mode to schema_only_recovery
3. recovery operation begins, let it complete ~50%.
4. restart the docker container
5. container stats, detects that history topic exists, offsets exists = all good
6. wait for connector to complete starting
7. make mysql data change in some table where recovery snapshot didn't yet cover
8. witness task crash :/