Feature/state machine

[incorbador]

The main idea of this PR is to remove all "hard" logic from @corabdo/react and to move it into the flowHandler.

Basic concept:

• UI components emit events only and react to state updates from the flowHandler => they only contain state if this state is specifically needed for the framework to work (they no longer hold e.g. the email of a user)
• the flowHandler holds a state-machine where every screen is a state (this is not completely new, previously flowHandler already was a bit like a state machine)
• for each state we define events that can either update the current state, change to a new state (screen) or change the flow
• @corbado/react connects to the flowHandler through FlowHandlerProvider

Advantages of this approach:

• easier to maintain (logic + state is concentrated in a single place)
• UI packages are easier to write (components just need to emit events, these events almost always correspond to user clicks so its quite easy for the developer to manage them)
• errors can be handled where they are created (inside the flowManager)

Disadvantages:

• quite a bit of refactoring
• we are not as flexible anymore because UI components can only emit events now and no longer call functions as they want => this will constrain us, but in the end this can also be a good thing, because it forces us to be consistent in our logic between all frameworks

Future refactoring:

• the definitions of flows have grown now => we can split them into one file per screen later, if we want

Additional changes:

• Update the NonRecoverableError screen to match the Figma
• Make sure that projectConfig is fetched before the component is shown (this is important to catch the error where a user would configure a wrong projectId)
• Shorten the error keys in our translation files (the previous prefixes like "validation_error" or "server_error" are mainly driven by our backend and are probably hard to understand for users => I would opt for these shorter names)

[Aby-JS]

My opinion for loader is, since Auth components are more like login/signup pages we should let the user handler their loaders and, if not that, then atleast make it customizable so that they can replace the loaders.
My suggested solution is to just let users handle the loader and emit an event when our component has been initialized.

[incorbador]

The easiest way for now is to have the Loading Spinner I think (for us its just adding this single component here and a bit less for the developer to take care of). If people ask for that functionality (controlling the loading by themselves), we can just as you say expose the initialised info).

[Aby-JS]

should we add translations for error boundary component?

[incorbador]

Yes valid point. For the NonRecoverableError component that we only show in DEV mode, English is fine I think. But for the generic error page, we should have a translation I think. I will add one.

[Aby-JS]

let's follow a similar convention to:

"passkeySuccess": {
      "header": "Welcome!",
      "subheader": "Passkey created",
      "body_text1": "You can now confirm your identity using your ",
      "body_text2": "passkey or via email one time code",
      "body_text3": " when you log in.",
      "button": "Continue"
    }

then we can call this:

"unexpectedErrorSupport": {
      "header": "Something went wrong",
      "subheader": "We’re sorry that our service is currently not available.",
      "body_withCustomerSupport": "Please try again in a few moments and if the issue persists, please contact {{customerSupportEmail}}.",
      "body_noCustomerSupport": "Please try again in a few moments.",
      "button": "Refresh Page"
    }