GPL-570 Refactor cherrypick task

[KatyTaylor]

User story As a developer I would like to refactor the code in the cherrypick_task class, so that it's easier to maintain. We found it difficult to read and modify while developing these two stories, during the 'bulk cherrypicking' epic - https://github.com/sanger/sequencescape/issues/2763 & https://github.com/sanger/sequencescape/issues/2783

The main method to refactor is called perform_pick. It adds the wells onto the destination plates in one big loop. This gets complicated when certain wells are pre-allocated, like through controls, templates and partials. You have to do things like 'look ahead' in the loop and see if you have enough wells left to fit all the remaining controls in. We think it would be simpler to fill in the pre-allocated wells first, and then go through and fill in the normal samples.

Who are the primary contacts for this story Eduardo, Katy

Acceptance criteria To be considered successful the solution must allow:

• cherrypick_task file, especially perform_pick and included methods are easier to read and understand.
• All tests still pass, no existing functionality is broken

[JamesGlover]

Have a long term desire to reimplement cherrypicking to get away from the tangled batch/pipelines/workflows stuff

1) Add the ability to form 'pick-lists' easily, without the need to go through all the paperwork of making submissions. 2) Avoid the need to go via the tangled batch/pipleines/workflows stuff, either as a new add, or just something else. 3) Improve flexibility, such as allowing changes right up until actually picked.

If we approach this sensibly we'll have some nice components to use in other contexts to allow gradual improvements of cherrypicking.

[emrojo]

First version:

• [] Creating an empty new gem
• [] Identify the files of actual cherrypick and select a small set
• [] Put everything in gem, run tests and test with SS

Second version:

• [] With a full set of every cherrypick model/lib class into the gem

Third version (optional):

• [] Change the gem into an engine
• [] Move cherrypick specific controllers/views/routes.rb maybe models?
• [] Move feature tests

Fourth (optional):

• [] Refactor in code or in services

[rl15]

On 4th August agreed that as a team to Book a meeting Generate options on what we could do Agree as a team one of the options Do it.

[JamesGlover]

CherrypickTask#can_link_directly is currently set to return false, as the current WorkflowsController tightly couples the first and second steps. This is as performing the previous action, and rendering the next are performed in the same controller action, and share instance variables. These variables then get rendered as hidden fields in the CherrypickTask template.

We could break this coupling by storing all the results of the form, not just the robot id in the descriptor. You'd still need to fill out the previous step once, but then could skip to the second easily.

Mostly though the advantage of this is that stage can be separated into two distinct actions, a create for performing the action, and a get for rendering it. (Other pipelines permitting)