Race condition in HiLoIdRepairUpgradeTask and ResetHiLoAfterImportListener can lead to primary key violations in upgrade tasks

Resetting the ResettableHiLoIdGenerator now happens in two parts:

• the HiLoIdRepairUpgradeTask determines the lowest possible safe 'hi' value and puts it in the database
• the ResetHiLoAfterImportListener forces the configured ID generators to retrieve the next hi value from the database

Unfortunately there is a gap between the two during which more IDs may be assigned by other upgrade tasks. In Studio's case, the InitApplicationKeysUpgradeTask was being run with stale ID generators, causing really hard-to-track-down duplicate key errors.

The ResetHiLoAfterImportListener was installed to make imports safer in a cluster (previously, the generators were only being reset properly on the same node as the import was performed). My recommended fix would be to create a specific HiLoIdResetEvent event that is thrown by the HiLoIdRepairUpgradeTask specifically for the ResetHiLoAfterImportListener, so that the IDs are all properly reset on all nodes before the restore continues.