fix: Mitigate shareable procedure flyout bug.

[johnnesky]

The basics

• I validated my changes

The details

Resolves

Fixes #2484

Proposed Changes

Prevents deletion of a procedure call block inside a flyout in response to deleting the associated definition.

Reason for Changes

There's a bug where call blocks in flyouts get disposed twice, and the second time results in an error getting thrown that prevents opening the flyout.

Flyouts do not get immediately rerendered or updated in response to a block being deleted. However, when opening a flyout, they do dispose any blocks that they already own before re-rendering themselves. If one of these blocks was already disposed, it'll get disposed a second time (which fails). This PR prevents the block from getting disposed the first time, so that the flyout can successfully clear itself.

It might seem like a problem that a flyout that is open can continue to contain a call block for a procedure that doesn't exist anymore. However, if this call block is dragged to the workspace, the procedure definition will reappear.

This is the same workaround implemented by code.org in: code-dot-org/code-dot-org#63662

Alternatively, we could investigate properly re-rendering the flyout in response to changes in its workspace, but that might involve changes to core blockly?

Test Coverage

I tested manually.

Documentation

N/A

Additional Information

N/A

[RoboErikG]

@johnnesky The change looks good but please make PRs against develop instead of master.

Edit: Whoops, wrong repo for develop. Nevermind!