Make state sync state machine more robust

[mikhailOK]

It seems like currently the Client has state_sync and catchup_state_syncs only in memory, but the state sync logic writes to db (ColStateParts).

Implementing #3262 requires more state-dependent logic to write / clean up data in db, so it would be a good idea to persist the state of syncing (ShardSyncDownload), and have atomic writes for state transitions and rollback/cleanup logic from any state.

[stale]

This issue has been automatically marked as stale because it has not had recent activity in the last 2 months.
It will be closed in 7 days if no further activity occurs.
Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity in the last 2 months.
It will be closed in 7 days if no further activity occurs.
Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity in the last 2 months.
It will be closed in 7 days if no further activity occurs.
Thank you for your contributions.