Dataflow: update fieldFlowBranchLimit semantics

[aschackmull]

This makes two changes to the fieldFlowBranchLimit interpretation:

• The count is adjusted to properly count virtual dispatch instead of nodes. This will block less flow and hence result in more computation and more alerts - hopefully fixing some FNs.
• The blocking condition on return edges is changed to only care about virtual dispatch count and not the number of call sites. This will block more flow and hopefully reduce FPs and performance problems based on uncertain dispatch. This has anecdotally been identified as the core issue in a couple of poorly performing cases.

For the return edge condition, special care is taken to still follow call edges that are determined by the call context.

All qltests are also updated to use the default fieldFlowBranchLimit instead of an inflated value to better reflect what's actually used in queries.

[MathiasVP]

n.hasInstructionAndIndirectionIndex(instr, index) may actually hold for multiple (instr, index) pairs, so this predicate really should be called getAnInstruction. Additionally, this seems to miss a case for IndirectOperands which I guess means that slightly fewer nodes than expected will have a second-level scope. However, since the shared library handles missing second-level scopes it's probably not a big deal.

The C/C++ team will probably fix this once this PR has been merged 👍 There are some more follow-ups that we want to do, and I'll write these up as an internal C/C++ issue.

[hvitved]

LGTM, one question.

[hvitved]

Why is this restriction needed?

[hvitved]

So we are only considering contexts ctx that we also return to; why is that? (and I guess that answers my question above).

[aschackmull]

This ensures that a call-context is always associated with the dispatch fanout at call. Either this is nested flow-through, in which case the context will be active in the initial flow-in when entering call, or this is returning flow that didn't come from a parameter in which case the return-call-context will be the thing that reduces the eventual fanout. This does miss the case where we enter the surrounding scope with a call-context and flow-through at call without returning further, but I think that's ok - for the "MaD model does lambda callback" case this would only be problematic if there were two lambdas being passed in with flow through the first and then entering the second. If we used the dual constraint not fwdFlow(out, false) to ensure a call-context from a parameter instead, then we'd miss the important case where a source is inside the lambda callback. So to cover this case we'd need a separate range on contexts to count, and I don't think that's worth the effort.