Fix #284, "fixed_step_algorithm crashes when a variable is reconnected"

[kyllingstad]

The problem was that fixed_step_algorithm::impl::disconnect_variable() didn't check whether it pointed to an actual element before trying to erase it.

This PR also fixes an unrelated hidden bug in the same function: The conns variable was a copy of the connection list, and not a reference to it as was intended. This would have rendered the entire function a no-op.

[mrindar]

Why are we trying to disconnect or erase a connection that doesn't exist?

EDIT:
Ah. So the function loops through all the simulators, looking for the one that has the variable in question as an outgoing connection, and erases it. Previously it crashed, because for it to work the variable had to, by chance, be in the first simulator in the simulators_ list?

[eidekrist]

Great! It would however be nice to see this tested - just something as simple as adding the same connection twice.

[kyllingstad]

@mrindar:

Ah. So the function loops through all the simulators, looking for the one that has the variable in question as an outgoing connection, and erases it.

Almost. It looks for the one that has an output variable which is connected to the input variable in question.

Previously it crashed, because for it to work the variable had to, by chance, be in the first simulator in the simulators_ list?

The loop body would crash for all simulators that did not have the connection. Maybe we just haven't tested this functionality yet, or maybe we've only tested it in cases where simulators_ contained only the one simulator.

[kyllingstad]

@eidekrist:

Great! It would however be nice to see this tested - just something as simple as adding the same connection twice.

And here I was hoping to get away without it. :D But I agree and will fix.

[kyllingstad]

Test added now.

[ljamt]

This looks good 👍
As the test requested by @eidekrist is included now we can merge.