Feature request: Avoid trapping users in bad editor state due to change detection

[akphi]

There are a few problems with change detection right now that we should address to unblock users: i.e. to allow users to save their models in those case at least. In particular, we should do the followings:

TODOs

• Allow change detection to be failed by hash computation error, right now we do nothing on hash error
• CHECK Block normal syncing while change detection is running as this might cause SDLC to throw entity already exists/created error
• Support hard-save functionality that will just save all entities (i.e. like model loader) without computing the entity changes
  • Add this button to local change panel
  • MAYBE If the quick-save call fails, show a dialog or something to prompt for disabling change detection
• When there's a problem with change detection, disable it (turn if off).
  • Show this in status bar (refer to how VSCode shows ESLint disable)
  • Show some icon in local change panel
  • In this mode, syncing is replaced by hard-save and we should put a blocking modal to confirm user's intention, something along the line of: change detection is disabled, so we cannot identify the changes you made locally in order to optimize save, this save action may take a long time, so be patient.
  • Make sure if change detection is disabled, the refresh action, quick-save action on the panels are disabled too, and the diffs are not shown (also can show a warning placeholder in the panel to say change detection is not running)

Improvement

• In case change detection is broken or reporting false positive, we can technically get the models from SDLC, and compare JSON-to-JSON with the entities being serialized from Studio graph to do a one-off change detection to help quick-save; this would be more efficient than hard-save but a little more complicated to implement so we will handle this later.
• We should re-evaluate and check what this would mean for the standalone review page (there, if diff is not showing, we need to call comparison API from SDLC instead).
• We should also re-evaluate what this would mean for conflict resolution: the fact that change detection is failable might means we need to block conflict resolution accept operation and modify SDLC API