openxr_data: fire VREvent_Quit event when session state changes to STOPPING

[ImSapphire]

Tested in VRChat via closing with WiVRn's quit button.

[Supreeeme]

Sorry for the delay. Looks good, but a test for this would be cool.

[ImSapphire]

Sorry for the delay. Looks good, but a test for this would be cool.

I'm not exactly sure how to write unit tests, and I'm working on some other things right now, would it be fine to merge without a test?

[Supreeeme]

1. I realized this is actually session loss, not instance loss. The commit message should probably be reworded.
2. I was thinking about this and came to a realization: is telling the application on session loss really the right thing here? To me VREvent_Quit seems more like a way to tell an application to gracefully close, but session loss seems closer to an error condition, and if we have applications gracefully exit it won't be obvious something erroneous happened. I would think session state being STOPPING or EXITING would be more appropriate.

[ImSapphire]

@Supreeeme Would emitting VREvent_Quit event on change to STOPPING state be enough? I thought there would be more involved in that case, though I guess nothing in OpenXR mandates that the app stop immediately

[Supreeeme]

Based on the spec, I think the correct thing to do would be:

1. Send VREvent_Quit on STOPPING
2. Call end_session (xrEndSession) when the application calls AcknowledgeQuit_Exiting

[ImSapphire]

iirc in SteamVR, AcknowledgeQuit_Exiting just extends SteamVR's kill timer to give the app time to safely shutdown, if we stop the session there we'd probably crash because the game would keep calling functions like WaitGetPoses, Get*ActionData etc. Not sure what the right thing to do there is

[ImSapphire]

Some apps also simply don't call AcknowledgeQuit_Exiting (VRChat, Resonite from what I've tested so far)

[ImSapphire]

Added a test

[ImSapphire]

@Supreeeme is there anything I could do to get this merged?