Make drop moves self-timing

[EvanKirshenbaum]

As I've been working on mixing (#21), I added a task that

• Dispenses n drops and walks them to the appropriate configuration
• Runs the mix operation
• Walks the lead drop to the top well across and the other drops to the bottom.

In an effort to make that last step look good, I've spent far too much time working out the appropriate delays on paper. It would be really nice to see if I can figure out a way to have it done automatically.

To a first-order approximation, I basically want to say "if the place I want to walk to isn't safe" (i.e., is a neighbor of a cell with a drop) "wait and try again next time". That should sort of work, but I can see a couple of wrinkles:

1. It could be the case that two streams of drops want to cross one another, and one of them never gets a chance. If that stream backs up, it's possible that it could block the first one, causing gridlock.
2. If you have a situation like

   A _ _ _ B

   where A wants to walk right two steps and then turn down and B wants to walk left two steps and then turn, on the next tick you'll have

   _ A _  B _

   and then you deadlock, as each sits there waiting for the other to get out of the way.

So, obviously, some more intricate scheduling would be needed.

Migrated from internal repository. Originally created by @EvanKirshenbaum on Jun 21, 2021 at 6:29 PM PDT.

[EvanKirshenbaum]

This issue was referenced by the following commits before migration:

• c9c269032b215b1a07f8c77cb22226ae332ebc06 by @EvanKirshenbaum on Jun 27, 2021 at 1:07 PM PDT
• 03e95b2ac756178f8f9e718408ebbc5ac01992ef by @EvanKirshenbaum on Jun 28, 2021 at 10:43 AM PDT

[EvanKirshenbaum]

I've added the basic safety checks on motion and dispensing:

• A drop won't move (unless an allow_unsafe parameter is provided) unless
  • the destination is empty
  • all of the destination's eight neighbors (except the motion source) are empty.
  • if the pad is an exit pad, the pad's well's gate is off.
  • no other move operation has reserved moving onto the destination in this tick.
• When dispensing:
  • The well's gate won't turn on unless the exit pad is empty.
    • Note: I'm not actually sure whether we need to look at neighbor's, too. I'm assuming not, for now.
  • The exit won't turn on unless it and its neighbors are empty.
  • A dispense motion won't merge into an ongoing motion if the ongoing one is already dispensing to this well.

In all of these cases, we just delay a tick and re-check. The effect is that I now no longer need to add after delay parameters to any of the tasks, including being able to schedule dispensing all drops for the mix task at the same time.

Note that we may run into problems if the delays (especially in dispensing) wind up executed in a different order. As currently implemented, any that are delayed will always be retried in the same order, but I'm not sure what happens if another one gets added while we're checking. It might get tried (for the first time) before the others get re-checked.

This is not a full solution, as it doesn't address fairness or deadlock avoidance, but it should make creating the paths a fair bit simpler.

Migrated from internal repository. Originally created by @EvanKirshenbaum on Jun 28, 2021 at 10:56 AM PDT.