Fix pulse time

[micahwoodard]

Fixes bug where reward time is not reset after flushing valves. Now, reward time is reset after spouts are flushed. Confirmed that after flushing, reward amount returns to reward volume.

[micahwoodard]

Updated the workflow to have a SetRightRewardAmount subject to trigger calculation of reward. Sets right and left in init and controlled independently in calibration

[bruno-f-cruz]

I think if we are doing this, we may as well future-proof it and have "SetRightRewardAmount" be a Tuple<Bool, float> similar to SetIsRightValveMs. Once we do that, SetIsRightValveMs will become private to the OperationControl scope (currently a global subject shared with the UI components) and the flush will instead use the SetRightRewardAmount, which becomes the public interface. The advantage is that it gives an obvious interface to implement single-trial-level reward amount modification in the future, should we need it.

[micahwoodard]

@bruno-f-cruz implemented SetRightReward amount and tested on rig

[bruno-f-cruz]

Made a couple of small changes for consistency and readability.

One important thing worth noting. While you decided to use "50"ul (instead of 500ms), the delay between pulses is still 500ms (hard-coded). You will now also have to calculate the "expected" delay for 50uL in the UI logic and await that period of time (probably worth adding a fudge factor). Since the hardware doesn't know anything about volume, and only time, I don't think there is a better way to do this. (Unfortunately, the harp behavior does not report when the pulse is done...).

Let me know if this is not clear, and we can talk about it.

If you do not calculate it you run the risk of the valve opening again before even closing (not sure if this is ok or not) OR waiting for too long to reopen it.

[micahwoodard]

New workflow looks like

[bruno-f-cruz]

Small note, you are committing from the service account