Fix redoPlacement race condition

[mourner]

Closes #3700. The condition occurred when a tile requested redoPlacement (which sent a redoPlacement request to the worker) and then shortly got removed (before getting response to redoPlacement back from the worker) — stopPlacementThrottler did not prevent redoPlacement from running in this case because it was past the throttling phase.

• briefly describe the changes in this PR
• write tests for all new functionality
• manually test the debug page

[mourner]

Not sure if it's worth adding a test for this tricky condition if the placement code is fully rewritten in the viewport-collision branch anyway.

[ChrisLoer]

I think this change would turn the redoWhenDone functionality into a no-op. Looking back even before the throttling changes went in, the behavior used to be that the tile state would be 'loaded', but another placement request would happen. I think that was a bug -- the state should have always been switched to 'reloading'.

Did the throttling changes cause #3700, or did they just change the timing so that it was easier to expose this condition?

[mourner]

@ChrisLoer fixed it to add the reloading state on redoWhenDone. If you think we'll do one more release before the viewport labeling PR is finalized, this is worth merging, otherwise we should close to reduce merge collisions. Not sure what caused the regression in the first place but throttling could be related.

[ChrisLoer]

Cool, I think it's worth merging.