Prevent duplicate permitted next nodes

[floehopper]

Manually specified permitted next nodes

It's possible for a developer to accidentally include the same node key in the list of permitted next nodes multiple times. However, from a visualisation point-of-view, we don't want the same node to appear more than once. There were a couple of duplicates in the existing flows and so I've included commits to remove them.

Automatically detected permitted next nodes

Likewise, when auto-detecting permitted next nodes, it's legitimate for a next_node block to have multiple execution paths which return the same next node key. But we still don't want the same node to appear more than once in the visualisation. I've been working on converting all the existing flows to use the auto-detect mechanism and I know that (without this fix) some of them would indeed generate duplicates like this.

Expected changes

None

[floehopper]

It turns out there are a couple of duplicates in the existing flows - I'm going to add a couple of commits to this PR to remove them.

[floehopper]

I've now pushed the two extra commits to remove the duplicates and updated the PR description to explain the removal of the duplicates.

[chrisroos]

As far as I can tell, the GraphPresenter already handles the case where there are duplicate next nodes specified in the list of permitted next nodes, i.e. the same node won't appear more than once in the visualisation. I checked this by looking at the visualisation of the two flows updated in this branch:

• https://www.gov.uk/calculate-statutory-sick-pay/visualise
  • The maximum_entitlement_reached node is only shown once
• https://www.gov.uk/pay-leave-for-parents/visualise
  • The outcome_mat_leave_mat_pay node is only shown once

Having said all that, it certainly does seems more correct for #permitted_next_nodes to return a unique set of nodes. So, this all looks good to me.

[floehopper]

@chrisroos: Thanks. You're right that the GraphPresenter does seem to cope - I think it must be this conditional. However, that behaviour doesn't seem to be tested and the code is pretty hard to follow. And, as you say, I think it makes more sense for #permitted_next_nodes to return a unique set of nodes.

[floehopper]

Rebasing against master and force-pushing in preparation for merging.