No Recovery from failures during start-up & teleport

[mikhail-dcl]

Issue description

Start-up and teleportation processes are represented by a series of async operations that return Result (can't throw exceptions).

• The process can fail at any point due to the time-out, network errors and unhandled exceptions, leaving the game in an unpredictable state depending on the moment when the process was broken. If it happens the only solution is to re-launch the client
  • some steps can recover, e.g. if MoveToParcelInSameRealmTeleportOperation that involves waitForSceneReadiness fails, the player will be teleported back to the original point from where it was started
• However, providing such a fallback for every possible operation will be hard to maintain.
• When instead of teleporting within the same realm an initial start-up or realm change is involved it may lead to even worse UX (and exceptions)

Realm is unloaded without recovery

It's a proven issue: if ChangeRealmTeleportOperation executes ChangeRealmAsync up to unloading, but fails on loading a new one, the user will be left in the empty space without a realm.
There is a local protection to recover the previous realm but it's bound to the same cancellation token so if timeout has fired the recovery process will obey.

Potentionally, it can be resolved by providing a separate recovery function to the loading screen so it does not follow the centralized cancellation token.

Realm Navigator is improperly layered

RealmNavigator contains methods that execute teleport operations and at the same time - methods that can be executed from these operations. It's wrong from the design standpoint: the class should be broken down into 2: one which handled a series of teleport operation, and another one that exists on the level of the operations themselves

Realm Navigator is fragmented

RealmNavigator contains too many entries points for doing essentially the same: e.g. goto chat command and "Jump Back To Genesis City" call two different methods while they do essentially the same. In one of them IsParcelInsideTerrain is respected, in another one - completely ignored.
Those methods should be unified.

Proposed solution

Consider the following opportunities:

• Select a small set of operations that can recover, for them the overall gameplay is not interrupted, and the recovery goes in a predictable way
• For everything else introduce a generic mechanism that:
  • will drop the user to the login screen (a similar process to logging out) to ensure that everything is properly cleaned-up, and all loading processes can start over without consequences
  • show the popup denoting a human-readable error. For this purpose consider finding an existing notification popup, and modifying Result structure to provide user-friendly information (if possible). We don't need a wide variety of such "errors", simply something that the user will understand, and it will be clear to them that they can re-login
• Expand the mechanism of Result (a flow without exceptions) onto all parts that interface with ITeleportOperation and IStartUpOperation, such as RealUserInAppInitializationFlow to simplify exceptions handling and possible recovery