Compiling a list of potential improvements to the save / restore tabs logic

• If the initial workspace is the welcome page, then when the user chooses to restore their previous session, should we replace the welcome page with their previous tabs? Currently, we open them in addition to the welcome page.
  • Related: If the previous session contained a welcome page as one of the tabs that was saved, should we actually restore it? This could result in two welcome pages (if we also decide not to replace the current welcome page).
• Add E2E tests (some examples):
  • there is no saved state.
  • one of the tabs we're trying to restore references a connection that no longer exists.
  • one of the tabs we're trying to restore no longer exists (e.g. collection / database was deleted);
  • user declines restore tabs
• While connections are loading during a restore, the tabs simply remain invisible, and only appear once the connections have been successfully established. Instead, maybe we want some sort of fallback rendering to make it clear that we actually restored the tabs, they are just not ready.
• When we restore the previous session, should we also set the active tab from that session?
  • Normally I'd assume yes, but if Compass-Web is opened with a specific URL like https://cloud-dev.mongodb.com/v2/66ce1716209aca269796919b#/explorer/68127cb7809e6141c3baf0bc/sample_mflix/embedded_movies/find, and the user also restores the previous session, do we want to make this "initial workspace" the active tab, or do we want to make the previous active tab the active tab?
• If loading the previously saved tabs takes a very long time (this is possible in web where loading previously saved tabs is a network call), it's possible for the user to open a tab and trigger the state-saving middleware, hence overwriting the saved tabs, before the call to load previously saved tabs returns. Even though this is very unlikely in practice, it is possible in theory and we might want to explicitly handle this case.