Jobs SharedWorker

[dlrice]

Note for reviewer

To view the SharedWorker within chrome visit chrome://inspect/#workers

Purpose

A bug has been reported that duplicate job creation can occur upon job submission. This PR addresses that issue by having a single SharedWorker used across all instances of the uniprot website within a single browser. This is useful because:

1. The current job polling logic cannot update other tabs with new job submissions - this would require refreshing each tab. With the SharedWorker, job state will be synchronized across all uniprot.org browser tabs. You can observe this by opening two tabs, creating a job in one tab and then immediately seeing this job populate the jobs dashboard in the other tab.
2. The current job polling logic will have one polling loop for each uniprot.org browser tab. For example, with ten uniprot.org tabs, there will be ten polling loops, each checking to see if a job is complete. This is a duplication of effort from both the client's and job server's perspective. With the SharedWorker, only one job poller will run regardless of the number of uniprot.org tabs. This will reduce the number of requests made from the client machine and also the number of requests received by the server.

Note that we are now explicitly blocking the submission/viewing of jobs from mobile devices (we previously simply removed the links to these areas of the website). Now there will be explicit pages and messages to ask the user to switch desktop or laptop for this functionality.

Approach

• IndexedDB is the source of truth. The whole state flows directly from this. All interaction with IndexedDB is delegated to the worker.
• The SharedWorker will always be running, if supported.
• Reused existing polling scheduler logic.
• Reused existing reducer logic. However instead of returning state, simply save changes to IndexedDB and return the complete state afterwards.
• Message passing between main thread and SharedWorker using objects of this shape:

export type JobSharedWorkerMessage = {
  state?: JobsState;                 // <-- complete jobs state object
  jobAction?: JobAction;             // <-- job action to be applied
  messageAction?: GetJobMessageArgs; // <-- message to be used in main thread
};

• useSupportsJobs custom hook created to determine support.
• IfSupportsJobs used in main routing logic to wrap job-related routes. Async download logic also updated to handle this case.
• Renamed Tools-related variables to Jobs to accommodate Async Download which is a job but not really a tool.
• Moved most of job-related code to within the workers directory.

Testing

Created and updated.

• To test on your local machine use chrome://inspect/#workers

Checklist

• My PR is scoped properly, and “does one thing only”
• I have reviewed my own code
• I have checked that linting checks pass and type safety is respected
• I have checked that tests pass and coverage has at least improved, and if not explained the reasons why
• If needed, the changes have been previewed (eg on wwwdev) by all interested parties.

[aurel-l]

Small typo in name of file suported => supported

[aurel-l]

I know it's been tested on its own test deployment URL, but maybe merge this in a morning, just in case we need to revert anything quickly.