Add touch pan blocker to gesture handling for touch devices

[avpeery]

This PR implements the new map option gesture handling (see: PR #11029) for touch devices by requiring two fingers to touch pan. Touch actions affected by gesture handling is touch pan. Actions that involve tapping gestures (i.e. tap zoom) and actions that already require two fingers (e.g. pinch-to-zoom) are unaffected by implementing gesture handling.

Possible trouble areas: Stress test panning with two fingers to see if the alert flickers. Touch panning vertically with two fingers may occasionally trigger tilting or zooming map instead of panning. To address the issue with touch pitch (aka tilting the map) affecting touch panning with two fingers, touch pitch requires three fingers if gestureHandling is set to true.

To implement gesture handling to map set to true in the map constructor:

var map = window.map = new mapboxgl.Map({
    container: 'map',
    zoom: 12.5,
    center: [-77.01866, 38.888],
    style: 'mapbox://styles/mapbox/streets-v10',
    gestureHandling: true
});

Video demo:

RPReplay_Final1634082501.MOV

Launch Checklist

• briefly describe the changes in this PR
• include before/after visuals or gifs if this PR includes visual changes
• write tests for all new functionality
• document any changes to public APIs
• manually test the debug page
• tagged @mapbox/map-design-team @mapbox/static-apis if this PR includes style spec API or visual changes
• apply changelog label ('bug', 'feature', 'docs', etc) or use the label 'skip changelog'
• add an entry inside this element for inclusion in the mapbox-gl-js changelog: <changelog>Add touch device capability for gesture handling (require two fingers to touch pan)</changelog>

[rreusser]

The feature itself looks good to me. 👏 My questions:

Is the behavior of wheel and one-finger touches independently controllable? Or are we okay with one switch for both? (IMO: one is probably fine? Maybe give a quick thought to future-proofing in the event that someone comes up with a good reason to separate the two?)

Is there are more descriptive name than gestureHandling? Almost something like capturePageScrolling: true | false. interceptPageScrolling? blockPageScrolling? My issue with gestureHandling is that even if I remember the name of the parameter and what it does, I don't know what true or false mean except to try them both and then remember which is which.

[avpeery]

@rreusser Thanks for taking a look!

Is the behavior of wheel and one-finger touches independently controllable? Or are we okay with one switch for both? (IMO: one is probably fine? Maybe give a quick thought to future-proofing in the event that someone comes up with a good reason to separate the two?)

It is not independently controllable. Setting gestureHandling activates both wheel and one finger touch control. I think one switch for both is OK, but open to being independently controllable if there are strong opinions.

Is there are more descriptive name than gestureHandling? Almost something like capturePageScrolling: true | false. interceptPageScrolling? blockPageScrolling? My issue with gestureHandling is that even if I remember the name of the parameter and what it does, I don't know what true or false mean except to try them both and then remember which is which.

Great point. Two alternatives would be to either change the term to cooperativeGestureHandling (boolean), or keep gestureHandling and use enum values such as something like "cooperative" and "greedy" or "accommodating" and "grabby"

[ansis]

This looks great! Only found the one issue while testing

[rreusser]

LGTM! 👏 🎉