FIX: Reset ButtonStates when re-using eventData with SingleUnifiedPointer

[tspiller]

Description

When using SingleUnifiedPointer only a single pointer state is ever created and it is re-used for all incoming pointer input. As this is updated with the new event data we need to ensure that the ButtonState's FramePressedState is not left in any specific state of press as this is no longer relevant to the new input data.

Testing status & QA

Tested against repro project on Google Pixel 6. Original bug is stated as difficult to replicate - it doesn't happen often without the fix and I have yet see the issue again with the fix.
Run against All Tests for Input System as there is potential for issues with UI Tests.

Requesting further testing on UI particularly.

Overall Product Risks

• Complexity: 1
• Halo Effect: 2

Comments to reviewers

Please describe any additional information such as what to focus on, or historical info for the reviewers.

Checklist

Before review:

• Changelog entry added.
  • Explains the change in Changed, Fixed, Added sections.
  • For API change contains an example snippet and/or migration example.
  • JIRA ticket linked, example (case %%). If it is a private issue, just add the case ID without a link.
  • Jira port for the next release set as "Resolved".
• Tests added/changed, if applicable.
  • Functional tests Area_CanDoX, Area_CanDoX_EvenIfYIsTheCase, Area_WhenIDoX_AndYHappens_ThisIsTheResult.
  • Performance tests.
  • Integration tests.
• Docs for new/changed API's.
  • Xmldoc cross references are set correctly.
  • Added explanation how the API works.
  • Usage code examples added.
  • The manual is updated, if needed.

During merge:

• Commit message for squash-merge is prefixed with one of the list:
  • NEW: ___.
  • FIX: ___.
  • DOCS: ___.
  • CHANGE: ___.
  • RELEASE: 1.1.0-preview.3.

After merge:

• Create forward/backward port if needed. If you are blocked from creating a forward port now please add a task to ISX-1444.

[Pauliusd01]

I've tried to reproduce the original issue for quite a while and wasn't able to with these changes. Also, checked our touch samples for any other potential issues and did not notice any. If there's concerns with this change maybe it would be a good idea to add someone from the UI team as well?

[ekcoh]

Changes look good to me, am I correct this wasn't covered by any automated test? Would it be possible to add a test triggering the problem to avoid future regression in this area?

[tspiller]

Changes look good to me, am I correct this wasn't covered by any automated test? Would it be possible to add a test triggering the problem to avoid future regression in this area?

@ekcoh The original reported issue is so intermittent and difficult to test that I'm not quite sure what an automated test would look like. I believe there is a timing element to whether the button is being checked before/after being updated and this ensures that it's not considered 'pressed' before being fully updated.