Core: Add option to not report state change to SetState (bugfix)

[TryTwo]

bug: https://bugs.dolphin-emu.org/issues/13277

Frame advance was reporting the incorrect emulation state to prevent flickering UI updates, which was breaking debugger widgets and crashing dolphin. Replaced with the option to not report a state change on SetState().

Applied the new option in CodeDiff, because it's a similar quick, temporary state switch.

Breakpoints now work correctly, and playing from a breakpoint will finish the frame advance and then pause.

[iwubcode]

What is causing the crash when CallOnStateChangedCallbacks is called? Why does not sending the callback fix things?

[TryTwo]

You probably understand most of it.
if (system.GetCPU().IsStepping() || s_frame_step) exists to stop the UI from flickering (fast pause -> play -> pause UI updates) on frame advance, but forces the incorrect state to be reported (forces Running to be seen as Paused during frame advanced). This was causing a crash in the debugger after, I think, recent guard safety updates (#11554)..

Since having an incorrect state be reported seemed to be the erroneous thing, I removed it and confirmed it fixed the crash. Then I checked the purpose of that and it was for the UI flicker. So, I tried to optionally prevent the UI update call on frame advance, and it stopped the flicker without causing any obvious issues. Also, preventing it reduces unnecessary update calls in the debugger, which is good.

So to answer your question, CallOnStateChangedCallbacks does not cause a crash, it was the if (system.GetCPU().IsStepping() || s_frame_step) crashing and the CallOnStateChangedCallbackschange change was to preserve what was intended with fixing flicker.

Another component of the crash could be UpdateDisasmDialog being unnecessarily called, but fixing the state fixes things.

[JosJuice]

Seems like a reasonable approach, but I would like a comment about why we have the functionality to skip calling the state changed callbacks.

[TryTwo]

Split the commits. Added a comment, hopefully it's clear. Also, restored the callback for the last CodeDiff state that will persist at the end of the function.. It wasn't causing any issues, but for extra safety.

[iwubcode]

Just wondering if it it'd be possible to have a flag in the debugger to ignore a state callback, instead of changing the SetState definition for only this one piece of functionality

[TryTwo]

I'm happy to try any other ideas, but not sure how that'd work. Toolbar, MemoryViewWidget, CodeWidget, and CodeViewWidget are the most affected.

[JosJuice]

Personally I'm okay with the current state of the PR. Avoiding flicker is not something that's exclusive to the various debugger widgets – it also affects things like the Play/Pause button, and disabling/enabling checkboxes in config windows. I haven't been able to identify anything in the UI that should be switching back and forth rapidly when using frame advance, and the state changed callbacks are only used by the frontend.

One comment about the code: The way CodeDiffDialog.cpp is setting the state to paused looks like it has a time-of-check to time-of-use bug. Using CPUThreadGuard would be better. But let's leave that out of this PR, as it's a separate problem.