RumUserActionDetector should detect other gestures by default

[orevial]

Feature description

Flutter GestureDetector and InkWell both support a wide range of gestures to be detected without any additional user implementation :

onTap
onDoubleTap
onLongPress
onTapDown
onTapUp
onTapCancel
onSecondaryTap
onSecondaryTapUp
onSecondaryTapDown
onSecondaryTapCancel

Today RumUserActionDetector only supports onTap events which is really nice, but not enough when going further with an application. The long press, for example, is a common scenario in a mobile environment.

Note that scrolling in lists or other scrollable elements could also be detected and sent to Datadog (RumActionType.scroll exists but AFAIK it is never populated). Although this could probably be another issue entirely depending on how you want it to be separated.

Proposed solution

I guess RumUserActionDetector method _onPointerUp could be tweaked a little bit to handle more touch scenarii, but I'm not sure exactly how. It would also means that:

• Detection of the widgets down the tree should probably be adapted to support those events, e.g.:

  if (widget is InkWell) {
    if (widget.onTap != null) {
      elementName = 'InkWell';
      searchForBetter = true;
      searchForText = false;
    }
  }

  wouldn't work well.

• Datadog available range of actions could be extended : from enum RumActionType { tap, scroll, swipe, custom } to enum RumActionType { tap, longTap, doubleTap, ..., scroll, swipe, custom }

Other relevant information

No response

[fuzzybinary]

I've looked into this in the past and unfortunately it requires that we essentially reimplement GestureDetector to detect all the various gestures without interfering with battles in the GestureArena

At one point I raised a feature request with the Flutter team to give us more information out of the GestureArena, specifically telling us which detector won, which would actually make a lot of the tree traversal we do also not needed. Unfortunately, it just isn't high priority for them.

So definitely an enhancement I'd love to see but the current complexity keeps it at a low priority.

Btw, we don't have an out of the box way to capture scroll events at the moment, but you can use ScrollNotificationObserver in conjunction with startAction and endAction to get them if you want.