The ANY/ALL convergence setting doesn't change the behavior of approval nodes

ALL:
Some test cases we'll want to check:
EDIT: Some of these permutations may be wrong based on comments from @rebeccahhh. Whoever runs tests on these should double check that the premise is correct for each situation.
ANY convergence does trigger when one of the jobs completesANY convergence does not trigger if a converging node that would only progress on success actually failsANY convergence does trigger when a second converging node succeeds, even if the first one failedALL convergence does trigger when all the jobs complete with paths that correspond to their required path states (success paths only continue on success, etc.)ALL convergence node, that the node does not trigger.Wait I think I disagree with the statement as soon as one of the leading jobs finishes.
the ANY/ALL changes the logic of whether all or at least one of the parent jobs has to trigger.
I guess what I'm trying to say is ANY/ALL setting should change IF the node should be triggered -- not "WHEN".
e.g. in both cases I believe it will wait until all possibly triggering parents completes
Like to get @chrismeyersfsu to think about that and see if I'm right
So this is actually expected behavior, _but_ we could consider changing this to an enhancement.
The basics of this is that we have _always_ waited for all the parent to finish, ANY/ALL just allows the node to control its run on the status outcomes of it's parents.
Also, just to clarify, an enhancement would apply to any ANY node in a workflow, not just approval nodes
The beginnings of the change needed to change the behavior can be found here: https://github.com/ansible/awx/compare/devel...jbradberry:any-nodes-start-early?expand=1
This isn't nearly as big a deal as I initially thought.. After talking about this with @rebeccahhh, she explained how the default behavior for convergence nodes is to _always_ wait for all prior jobs to finish. I had incorrectly thought the default behavior to be the opposite of this when I created the issue - sorry!
With all this in mind, doing this enhancement would actually make the behavior _less_ consistent (though as the new title for this issue points out, it would make the job runs progress faster under some circumstances :man_shrugging:)
I'm closing this based on team discussions. This would not be an asset to our existing workflow structure and I don't think it merits much further discussion on here.