refactor: integrate react-query for execution data fetching

[schottra]

This is the first in a series of PRs which will update our execution data fetching to use react-query instead of a custom fetch hook and data cache

This change adds react-query and react-query-devtools and updates the hooks used at the top level of the ExecutionDetails page to use react-query for their data mangement.
Specifically, the hook for fetching the top-most Workflow Execution no longer uses the useFetchableData hook, but uses useQuery instead. I also updated the code for terminating an in progress Execution to use a useMutation hook and wait on the execution to reach a terminal state before returning. This was to make sure updates to queried data correctly invalidated queries which were reading that data (and it also happened to expose a subtle issue with the way query keys are generated and hashed).

Extended Details:

• Added react-query and react-query-devtools. I opted to use the 3.2 beta since it looks fairly stable and will be released soon, and because I had issues creating a query hash override function using the 2.x version.
• Configured the QueryClient to fail immediately on 401 errors and to serialize non-plain objects using object spread so that we get consistent keys when passing id objects which use prototypes generated by protobufjs.
• Updated useWorkflowExecution and useTerminateExecutionState to use react queries/mutations.
• Removed the terminateExecution property from ExecutionContext. This was a hacky solution to allow terminating the execution from deep within the component tree while allowing all consumer of the Execution to see the updated state once termination was complete. This is unnecessary with react-query because all observers of the query will be updated automatically.
• Added a WaitForQuery component, which is similar to our existing WaitForData component, but is designed to work with the return value from useQuery instead.
• Updated logic in the ExecutionDetails app bar header to not show the terminate button or extra actions until the execution has actually reached a queued or running state. Terminating an execution while it is in an Unknown state generally does not work correctly.
• Added a helper function that can be used by promise-based workflows to wait until a Query reaches a desired state. The termination flow uses this to delay returning from the terminateExecution call until the API returns a terminated execution record.
• Added a useConditionalQuery hook that allows a query to be conditionally executed based on the state of the data. This is used by useWorkflowExecution along with a refreshInterval to instruct react-query to continue fetching the Execution record until it reaches a terminal state (this preserves existing behavior we had around polling executions until they are terminal)
• Added an observer component that sits at the application level to intercept 401 errors and stop future queries/trigger the login flow. This preserves behavior that was previously handled by useFetchableData.

[BobNisco]

This is great stuff. Definitely some interesting work going in with the 401 observer, looking forward to seeing how this continues to progress over time 👍

[BobNisco]

Should this only be enabled in dev?

[schottra]

According to the docs, the import is a no-op in production, so this is safe to leave in.

[schottra]

I will try building prod mode locally to verify, and if that's not the case, I'll add logic in the next PR to conditionally render it.