Improve performance of inserting blocks into stacks.

[BeksOmega]

Describe the bug

Current performance on 7eebd78:

Time to execute endDrag = ~52 ms averaged over 5 trials.

Convert the following txt file to a json file and then load it into your Chrome Dev Tools to view the results:
inserting-1.txt

To Reproduce

Steps to reproduce the behavior:

1. Go to the playground.
2. Load the following JSON:

{
  "blocks": {
    "languageVersion": 0,
    "blocks": [
      {
        "type": "controls_if",
        "inputs": {
          "DO0": {
            "block": {
              "type": "controls_if"
            }
          }
        }
      },
      {
        "type": "controls_if"
      }
    ]
  }
}

4. Go to the performance tab of the chrome devtools.

5. Enable recording screenshots.

6. Set CPU Throttling to 6x.

7. Start a recording.

8. Insert the single block into the stack of two blocks so that it looks like this:
   

9. Stop the recording.

Expected behavior

Ideally, we wouldn't drop frames when inserting blocks. For this to be achieved, inserting needs to complete within 10ms.

Additional context

It looks like hidePreview_ is doing a lot of work (~22ms), and triggering a lot of re-renders I'm hoping that can be cleaned up.

Similarly with connect (~16ms).

This one is going to take some more digging though.

[BeksOmega]

So after some work on this, imo removing the extra render calls needs to be more of a project (with an actual design doc and whatnot). Currently our only way to delay/remove some of these render calls is to set block.rendered = false and block.rendered = true which is error prone, and has historically caused us problems as documented in #4288

Also going to link this to #5375 as refactoring insertion markers will have to take into account when we trigger renders.

[BeksOmega]

To clarify my previous comment: When we're inserting a block, we're actually "rendering" a lot of "stages" of connecting the blocks that never get drawn to the screen. If you use breakpoints you can step through and see them.

After first "dropping" the block:

Disconnecting the child from the insertion marker:

Connecting the child to the surrounding parent parent:

Disconnecting the child from the parent again:

Connecting the block we dropped to the parent and the child: <-- This is the only thing that actually gets drawn to the screen

So if we could prevent those first 4 render calls, it would gain us a lot of efficiency. But as mentioned in the previous comment, our current way of doing that isn't very maintainable.

[BeksOmega]

So I dug into eliminating the duplicate renders, and it's a bit buggy, but I got some really promising efficiency improvements! ~5x faster for dragging JS spaghetti blocks.

What I'm doing is creating a tree of blocks that need to be rerendered (so for each leaf block that needs to be rerendered, it also adds all of that leaf's parents). Then inside a requestionAnimationFrame callback I'm rerendering all of the blocks depth-first (so all children get rerendered first, which is necessary for the parents to properly render).

Additionally, I added a delay to the bringToFront call in the insertion marker manager, which really improves performance because it means we don't have to do so many style/layout calculations immediately.

Changes are on https://github.com/BeksOmega/blockly/tree/exp/render-queue