Break executeCommands into functions

[javagl]

The Scene.executeCommands function had >400 lines and did ... a lot of things, with a lot of redundant redundancy. Sometimes obvious, around the pattern

    uniformState.updatePass(...);
    commands = frustumCommands.commands[...];
    length = frustumCommands.indices[...];
    for (j = 0; j < length; ++j) {
      executeCommand(commands[j], scene, context, passState);
    }

(with commands, length, and j being defined at function scope and re-assigned all over the place). Sometimes, with subtle differences, where the above block was just

    uniformState.updatePass(...);
    commands = frustumCommands.commands[...];
    length = frustumCommands.indices[...];
    for (j = 0; j < length; ++j) {
      executeIdCommand(commands[j], scene, context, passState);
    }

This PR breaks the executeCommands function into smaller blocks, reducing redundancy, adding comments etc.

This was just quickly written down. while trying to roughly understand some aspects of what's going on there. So this PR is rather some sort of "internal notes", and opened as a DRAFT, and will likely be closed without merging. The main reason for opening it is to ask whether "something like this" could be considered to be of value (and whether it should be reviewed and tested with the goal to bring it into a mergeable state), or whether such a change is "too drastic" and contains too many risks for bugs to ever be merged anyhow.

[github-actions[bot]]

Thank you for the pull request, @javagl!

:white_check_mark: We can confirm we have a CLA on file for you.

[jjhembd]

I think this could be a valuable change.

or whether such a change is "too drastic" and contains too many risks for bugs

A refactor here could reduce the risk for bugs. I remember having to track down several bugs in https://github.com/CesiumGS/cesium/pull/11828, which were caused by my not understanding what was happening in executeCommands

[jjhembd]

Hi @javagl, I ran into similar issues while trying to trace through how we generate our depth buffers. I incorporated several of your ideas in https://github.com/CesiumGS/cesium/pull/12188.

If https://github.com/CesiumGS/cesium/pull/12188 makes sense to you, we could close this one.

[javagl]

@jjhembd I looks like the linked PR will indeed make this one obsolete.

(This one was rather a "proposal", and I'd have to re-do most of the changes from scratch, with more diligence, more fine-grained commits, and more intermediate test passes to be sure to not break anything).

And in any case: The state that results from the other PR would overlap with this one in a way that would make this one unmergeable.

So I'll close this one, and try to review the other one ASAP (hopefully today). I might not be able to say much about the "correctness" of certain changes, but will at least do a pass over the commits, changes, and test it a little....