Handle iam outage more gracefully, related to #321

[Phillezi]

Handle iam outage more gracefully, related to #321

• Created a context that wraps ReactKeycloakProvider and makes AuthClientEvents and AuthClientErrors available.
• Implemented a check if there is an error inside ProtectedRoute.tsx and if there is an error just redirect to / (the landing page).
• In the landing page a snackbar will be enqueued if an error (from the AuthContextWrapper) is present, and the landing page will appear as if you are logged out.

Some considerations I have:

Is wrapping the ReactKeycloakProvider a good solution? Or should it be solved in another way? Might be possible to do it a bit neater, I am currently just doing it like this: (also: events could just be one singular event)

const [events, setEvents] = useState<AuthClientEvent[]>([]);
const [error, setError] = useState<AuthClientError | undefined>(undefined);

const handleEvent = (
  event: AuthClientEvent,
  error: AuthClientError | undefined
) => {
  setEvents([...events, event]);
  if (error) {
    setError(error);
  }
};
return (
  <AuthContextWrapper.Provider value={{ events, error }}>
    <ReactKeycloakProvider authClient={authClient} onEvent={handleEvent}>
      {children}
    </ReactKeycloakProvider>
  </AuthContextWrapper.Provider>
);

It still takes a while until the ReactKeycloakProvider calls the onEvent callback I am using, I am not sure why that is the case.

Should it redirect to the landing page and display a message like i've implemented it now (a snackbar is enqueued). Or should it display a separate page/modal/dialog where maybe a link could be added to the uptimerobot site.

Lmk what you think

Related to #321