ScrollContainer with a deadzone suddenly snaps/flickers on touch

[threethan]

Godot version:
Tested on 3.2.3, 3.2.4, and a build of 'latest' (4.0) made today.

OS/device including version:
Issue is only present on mobile. Device tested was a Samsung Galaxy S8 US with a Snapdragon 835 SOC. Tested with GLES3 for 3.2.3, 3.2.4 and Vulkan for 4.0/'latest'

Issue description:
Issue occurs on actual touch screens only, when interacting with a ScrollContainer node that has a deadzone.
Expected behavior:
When passing the deadzone, the container will scroll starting from its current position and continuing smoothly from there. The expected behavior can be observed when using a mouse and enabling 'Emulate touch from mouse' in the project's settings.
Problematic behavior:
When passing the deadzone, the container will instantly scroll a large and unpredictable amount for one frame. If the drag motion continues, the scroll will typically snap back to the expected position. However, with slow finger movement, it will flicker between scroll positions.

Steps to reproduce:

1. Create a ScrollContainer node, and give it content that is large enough to allow scrolling.
2. Set the deadzone of the ScrollContainer to a value above zero. (The snapping behavior is more noticeable with large values, while the flickering is more noticeable with smaller values)
3. Run the project on a touch screen device and attempt to scroll the container with your finger. (Slower movement cause more noticeable effects) (This does not occur with emulated touch, only on an actual touch screen)

Minimal reproduction project:

ScrollTest.zip

I have already found the cause of this issue and will submit a pull request fixing it shortly!

[threethan]

While I haven't tested if this is fixed by another PR, #62289 DOES NOT fix this issue.
#62289 seems to fix many similar issues, but the issue mentioned here is due to an issue in how deadzones are handled in scene/gui/scrollcontainer.cpp. #62289 addresses an input processing issue, does not modify scene/gui/scrollcontainer.cpp, which I have confirmed to be the source of the issue (see #47931)