Feature/treat warning messages as warnings

[schoinh]

Problem

Now that we get warning, info, and error messages differentiated from the viewer, we should treat warnings and info messages differently from error messages.

Closes #269

Solution

1. Currently, the setStatus action does 2 things: set the viewer status (empty, loading, error, or success) AND set the error message in state. Setting the viewer status to "error" has effects we don't want with a warning or info (for example clearing out the agent panel), and in fact we don't want to change the viewer status when we get a warning or info at all. So I split up setStatus into setStatus and setError. Now, setStatus only sets the viewer status (empty, loading, error, or success) and setError puts the error message (with various error levels like warning, info, error) in our state so they can be turned into notifications for the user.
2. Modify the ErrorNotification component so that it displays warning and info icons (instead of a red X) for warnings and infos

Other stuff

• Installed esbuild-jest and esbuild (required by esbuild-jest) to modify the jest config, which fixed this annoying problem we've had forever, where the test suite would break if we imported @aics/simularium-viewer into src/state/trajectory/logics.ts. This was necessary in this PR because I needed to import simularium-viewer into that logics file! (I'm honestly not sure why this config fixed the problem or why the problem existed in the first place, it was just a lot of trial and error)

Type of change

Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)
• This change requires updated or new tests

Steps to Verify:

1. Pull this branch and npm i then npm start
2. Load a file that needs local geometry files, but don't supply the geometry files
3. You should see some warning messages pop up (instead of error). Everything else should work as before.

Screenshots (optional):

Keyfiles (delete if not relevant):

2. src/state/viewer/reducer.ts & src/state/viewer/types.ts - separate out setStatus into setStatus and setError
3. src/components/ErrorNotification/index.tsx - take error level into account when rendering a notification

Almost everything else is just having to update code everywhere setStatus has been used.

[schoinh]

I updated this to try to fix something I think is a bug with redux -- it didn't fix it, but it didn't break anything else either, so I kept the update

[schoinh]

This is rolling back the temporary fix I put in for #274

[github-actions]

jest coverage report 🧪

Total coverage

Status	Category	Percentage	Covered / Total
🟡	Statements	74.7% (-1.3% 🔻)	514/688
🟡	Branches	70.94%	105/148
🔴	Functions	43.1% (-1.81% 🔻)	75/174
🟡	Lines	74.66% (-1.34% 🔻)	495/663

Status of coverage: 🟢 - ok, 🟡 - slightly more than threshold, 🔴 - under the threshold

Show files with reduced coverage 🔻

Reduced coverage

Status	Filename	Statements	Branches	Functions	Lines
🔴	actions.ts	53.84%	100%	0%	53.84%
🔴	reducer.ts	26.31% (-7.02% 🔻)	0%	0%	26.31% (-7.02% 🔻)
🔴	src/state/trajectory	37.42% (-1.08% 🔻)	0%	4.44%	37.42% (-1.08% 🔻)
🔴	src/state/viewer	58.73% (-3.77% 🔻)	0%	5%	58.73% (-3.77% 🔻)

Status of coverage: 🟢 - ok, 🟡 - slightly more than threshold, 🔴 - under the threshold

[meganrm]

set this to initial state

[schoinh]

You mean (pseudocode) return {...initialState}? I don't think we want to do that because we want to set the status to whatever the payload.status is. (like loading, empty, success -- the ones that aren't error)

[meganrm]

no I meant, error: initialState.error

[meganrm]

👍🏻

[meganrm]

I just tested this with a file I have that currently crashes staging, and it works, so thumbs up. I did leave one comment that I think it's best to always be setting things in state to either something coming through the payload or to initialState[key] just so it's clear what's happening, but otherwise, looks good