Feature/conversion check server

[interim17]

Problem

We want to ping the Octopus server to see if it is healthy before letting the user proceed too far along the auto-conversion workflow.

Closes #389

• New feature (non-breaking change which adds functionality)

Solution

This is the front end follow up to Alli's work, which set up the health check communication between the the Viewer and Octopus.

Reviewing this PR requires a dev build of the viewer, and a local instance of Octopus running, fun! A glimpse into the future.

Style things

I did a walkthrough of the modal styling with @lynwilhelm and have her approval on it. If you look at these designs you may notice that the auto-conversion designs are old and out of sync with the most current global style guidance.

For devs in review, if something on your machine looks/behaves dramatically wrong, or is vastly different than the screen shot, please let me know, but don't be too concerned about the design brief, Lyndsay and I are in touch about it all.

Hover state:

Code things

To check the server health we need to implement some logic to account for the fact that WebSocket requests don't have an automatic response if the request fails:

• first we now store conversionStatus in state: we were already storing status for the viewer in the Viewer Branch, I'm cloning that idea in the trajectory branch to track conversion status. I don't think VIEWER_IMPORTING was sufficient for this case, and I anticipate it will be useful to have a little granularity here going forward.

configureFileConversionLogic is where the action happens:

• check for a properly configured controller and set one up if needed

• then we define performHealthChecks a recursive function that will send a defined number of health check requests to Octopus, the health checks include a handler for when a positive response comes back, and a net connection config.

• a timeout waits a certain number of seconds before assuming the last check failed to get a response (would appreciate feedback on how long to wait here, thoughts in code comments)

• each handler goes out with a requestId and each requestId is stored along with a three second timeoutId in healthCheckTimeouts

• if a handler fires (meaning the server responded positively) we clear that set of ids from healthCheckTimeouts set healthCheckSuccesful to true and update conversionStatus to CONVERSION_SERVER_LIVE

• if a request times out with no response and healthCheckSuccesful is still false we try again until we reach MAX_ATTEMPTS and then set conversionStatus to CONVERSION_NO_SERVER

• this logic is triggered by the receiveFileToConvert action, which can be called with a null payload if we just want to do a health check

• ConversionForm sends a health check on load, and then another when a file is uploaded. If the conversionStatus is negative when we click the "Next" button, the modal should be raised.

Steps to Verify:

1) You need a dev build of the viewer installed in the website. Building from main will work. npm run build and copy the path of your viewer repo into package.json 2) You need an Octopus instance running locally at server ip "0.0.0.0" and port 8765, I can try to help you set this up if needed, @ascibisz is a also a wiz at this. 3) When your server is running, npm run start the website and go to http://localhost:9001/import or choose "import other file type" from the Load model menu. 4) Select Smoldyn for your conversion engine and upload any file that ends in .txt 5) Click next. If your server is running you should proceed to the next page, and also see a log of "conversion-server-live" in your console. 6) To test failure, repeat steps 3-6 without running your local Octopus instance. When you click Next you should see the error modal. 7) Similarly, if you turn octopus on between page load and file upload step, you should be able to advance. 8) Vice versa, if octopus is not running when you load the page, but then you turn it on, and then you upload a file, it should hopefully let you advance!

[interim17]

A couple updates:

We were updating the viewer status toVIEWER_IMPORTING to disable some buttons in the app header but it was not working well because any trigger of VIEWER_ERROR status would reactive the buttons. We don't need it now that we have conversionStatus so I removed it entirely and also updated both of the status types based on @ShrimpCryptid 's feedback.

The redux initializeConversion() action is now handling the configuration and conversion so we were able to thin a little code from a few other places and it should be more semantic now. Thanks for the ongoing feedback!

[ShrimpCryptid]

Copied over from another PR I accidentally commented on:

The cancel button is really faint when hovered.

Also, the delete button is invisible until hovering over the text filename.