Bubble sync points if ignore_deferred, do not ignore if target system is exclusive

[urben1680]

Objective

Fixes #17828

This fixes two bugs:

1. Exclusive systems should see the effect of all commands queued to that point. That does not happen when the system is configured with *_ignore_deferred which may lead to surprising situations. These configurations should not behave like that.
2. If *_ignore_deferred is used, no sync point may be added at all after the config. Currently this can happen if the last nodes in that config have no deferred parameters themselves. Instead, sync points should always be added after such a config, so long systems have deferred parameters.

Solution

1. When adding sync points on edges, do not consider AutoInsertApplyDeferredPass::no_sync_edges if the target is an exclusive system.
2. when going through the nodes in a directed way, store the information that AutoInsertApplyDeferredPass::no_sync_edges suppressed adding a sync point at the target node. Then, when the target node is evaluated later by the iteration and that prior suppression was the case, the target node will behave like it has deferred parameters even if the system itself does not.

Testing

I added a test for each bug, please let me know if more are wanted and if yes, which cases you would want to see.
These tests also can be read as examples how the current code would fail.

[urben1680]

Tagging @hymm as the original author of the modified file. 👋

[alice-i-cecile]

I'd like the tests to be more explicit about what the final inferred schedule looks like, and why that schedule is correct.

[urben1680]

I'd like the tests to be more explicit about what the final inferred schedule looks like, and why that schedule is correct.

As in doing more assertions on the schedule's internal values or adding more comments?

Btw I think there is some other problem to address. As it is now, bubbling a sync point further up means more than one sync point could be generated if there is more than one outgoing edge with each different distances. But that makes no sense, the original system that wants it's commands applied needs only one sync point.

I try to think what to do here. Until then I put this one into draft again.

[alice-i-cecile]

More comments mostly :) I had a hard time following what the internal logic of the tests were, and why they were correct.

[urben1680]

I was unable to trigger any issues I assumed to be there so I decided to not change my approach.

[andriyDev]

Great change!

[urben1680]

Merged @andriyDev's changes into this PR. I must confess both our changes together make this hard to understand. I probably will try to make everything clearer, maybe with more comments, other variable names or such stuff.

If someone has good ideas to make this more clear, please write them in a comment. 😃

EDIT: Done with my ideas, can be reviewed now

[alice-i-cecile]

Good test comments now! Thanks for tackling some cleanup work while you were here; I agree that this was getting quite tricky to follow 😅