Audit generic error screens for updates and modify the useError hook and error component to add better ways to handle individual cases

[jmarchi]

Proposed Change

The generic error screens used across the app via ErrorComponent have not been looked at by design/content recently In addition to updates we may want to make, this can lead to confusion around how errors are handled and what is a specific error for a screen or feature vs a generic error we handle through boilerplate code. The distinction is important for both UX when thinking through the error states and engineering for deciding how to handle it in code.

The generic error flow can also be expanded to include special cases where those cases replace the entire screen content. Certain errors that are handled by a single screen via an alert box or similar that do not replace the whole screen content are probably better left to specific variables in the store that can be set and reacted to since ErrorComponent is designed to be the only content on the screen.

Why Should We Prioritize?

Coding Time Estimation

[timwright12]

@dumathane is this ticket still relevant?