Enumerate frontend fixes needed to reduce request processing time

[mwinokan]

@boriskovar-m2ms please investigate what the quick wins, and high-priority bigger fixes that will help reduce the response processing time for API endpoints in #1427

[boriskovar-m2ms]

After the restoration of bigger snapshots was fixed in #1440 now I had opportunity to analyze snapshot performance because of many complaints in the past especially of big lag between pressing the SHARE button and dialog showing up with link to new snapshot.

Length of this lag is a function of number of actions performed during the lifetime of a session (for undo and redo functionality) and also number of actions needed to restore a snapshots (it's two different sets). There are several and severe inefficiencies as it can be seen on a case study below.

Snapshot performance:

saveAndShareSnapshot

orig snapshot: https://fragalysis.xchem.diamond.ac.uk/viewer/react/projects/47/49
created snapshot: https://fragalysis.xchem.diamond.ac.uk/viewer/react/projects/49/51

1. https://fragalysis.xchem.diamond.ac.uk/api/session-actions/?session_project=47
   GET
   10.4 MB
   gets all the project actions (what's difference between project action list and actions list - presumably it's snapshot actions?) - getTrackingActions and we want them copied to new project. Why? Don't we already have them? I pretty sure we do.
   Why don't we need only snapshot actions which we definitely have so I don't understand this step.

2. https://fragalysis.xchem.diamond.ac.uk/api/session-actions/
   POST
   10.4 MB
   copyActionsToProject - here using the sendTrackingActions we are sending copied actions to new project.

3. https://fragalysis.xchem.diamond.ac.uk/api/session-actions/?session_project=49
   GET
   10.4 MB
   we are downloading project (new project) actions again... which we already have because just moments ago we sent them there...

4. https://fragalysis.xchem.diamond.ac.uk/api/session-actions/197/
   PUT
   10.4 MB
   using
   updateTrackingActions - because it's just JSON we don't have granular control over updates so we need to update whole list so we need to send whole 10.4 MB payload

5. https://fragalysis.xchem.diamond.ac.uk/api/session-actions/
   POST
   2.6 MB
   saveActionsList - saveSnapshotAction - seems fine

6. https://fragalysis.xchem.diamond.ac.uk/api/snapshot-actions/
   POST
   3 MB
   saveActionsList - saveTrackingActions - seems fine

Fixes:

1. For sharing snapshot I think we just need step 6 because we don't need the undo redo list of creator of the snapshot.

2. For creating new project I think we should be able to skip steps 1 and 3 because we should already have this information.

There is also inefficiency in step 4. Here all the actions are actually just one field that stores JSON string so if we want to update an action or and new action we need to send whole new string which in this case is not insignificant 10.4 MB. This is also significant because if you are working on a session project then every 5 actions are sent to B/E and every time we need to send all previous actions + 5 new actions.

[mwinokan]

Thanks @boriskovar-m2ms, please implement the three fixes above.

I will talk to @phraenquex regarding using the state vs actions:

@boriskovar-m2ms says that previously snapshots used to work by transmitting the state rather than the list of actions needed to restore the state but it was changed due to the instability of ID's. Now that the ID's are more stable maybe we should revisit this.

[boriskovar-m2ms]

All of the fixes are now implemented not only for snapshot saving but also restoring.

[mwinokan]

@boriskovar-m2ms says it is definitely faster but there may be outstanding broken issues. Please push it to staging so we can test it in anger.

Regarding encoding state vs list of actions in the snapshot: Boris says that using the redux store should be relatively simple.

@boriskovar-m2ms please briefly investigate the work involved and the scale of the performance gain. @phraenquex also suggests using compression for the JSON payload