Implement memory-based undo/redo

[cjcenizal]

Background

Original proof-of-concept with TODO list: #8019

Changes

• Store undo/redo history in memory instead of in sessionStorage. This removes the storage limits involved with sessionStorage.
• Store the current state of the app in sessionStorage (not localStorage, to prevent conflicts between multiple tabs running Kibana), and reload it when the app is loaded. This satisfies the requirement for state to be sticky (Visualization and dashboard state, URLs, and sharing #7899 (comment)).
• Uncouple undo/redo from the browser history by adding undo/redo controls to every app's UI that needs them.
• Remove the hashes from URLs.

Browser history

The browser back/forward buttons will be used to help the user support their navigational history (e.g. changing apps, changing sections within an app).

Reloading the browser will probably wipe the undo/redo history (this is the behavior in Google Docs), but of course the browser history back/forward buttons will be unaffected.

We could theoretically retain the undo/redo history of a document by storing it in localStorage, so that a reload wouldn't wipe it, but I doubt this scenario will occur often enough for it to be useful.

[epixa]

The issue we have with localstorage is unexpected cross-tab pollution: a user uses Kibana in one tab and it directly affects the behaviors in another tab. I wouldn't expect undo/redo to affect any change I make on any tab, I'd only expect it to affect the changes I've made from the current tab.

Race conditions become a harder issue to address when the app needs to consider cross-tab state as well. This is true of data persisted in ES as well, but at least ES has mechanisms to avoid trampling on data in those situations.

[cjcenizal]

@epixa Thanks, I just updated the description to specify that current app state will be stored in sessionStorage. Also, I think I might not have been clear: the undo/redo history will be stored in memory (e.g. an array of state objects), not in storage. The only thing we need to persist in storage is whatever data is necessary to restore the state of the current app when the user refreshes the browser, since the URL will no longer persist that state (the undo/redo history will be lost).

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[timroes]

Closing this as too unspecific. If this is not about a central service (which would reside with App Services or Core), we have other issues to track undo/redo more specifically in some apps, e.g. #54971 for supporting undo/redo in Lens.