We have ~20 cases in our code where current UserGestureToken is saved at one point in time, and then later used in an UserGestureIndicator.  
This created a two-level state maintenance mechanism without a clear benefit as explained below.

But more importantly, this unnecessary complexity makes it very hard (if not impossible) to add an alternate implementation (for the simple model, Issue 696617) such that we can switch between them for testing.

[Why saving a token locally is either unnecessary or unpredictable]

UGIs maintain a single effective state through a static root_token which is updated through the UGI ctor as follows:
  [A] if the passed token == root_token (incl. both nulls):
      root_token remains unchanged
  [B] else (the passed token != root_token):
      root_token gets a fresh start (new gesture, new expiry deadline)

Now saved tokens have two usage patterns:
- For mouse events, a UGI is created before saving the root_token at mousedown, then the UGI gets out of scope.  The saved token is then reused to create a new UGI at mouseup; [B] implies this is like using a brand new token.  This is done in EventHandler, WebViewImpl, WebFrameWidget{Impl,Base}.

- The rest of the use-cases (DOMTimer, PostMessageTimer in LocalDOMWindow, ScheduledNavigation, SuspedableScriptExecutor) saves current root_token w/o creating one (so could be null), then reuses the saved token later on to create a new UGI.  The outcome depends on what happened to the old UGI in between: if it was destructed (with or w/o consumption), the new UGI is like a new gesture; otherwise the new token is ignored.  This seems unpredictable.

A simple solution: don't save token, but instead save the active gesture state (if there is any unconsumed gesture), and use the state to create a UGI later on.

So we won't need any UGT!
 

We have ~20 cases in our code where current UserGestureToken is saved at one point in time, and then later used in an UserGestureIndicator.  
This created a two-level state maintenance mechanism without a clear benefit as explained below.

But more importantly, this unnecessary complexity makes it very hard (if not impossible) to add an alternate implementation (for the simple model, Issue 696617) such that we can switch between them for testing.

[Why saving a token locally is either unnecessary or unpredictable]

UGIs maintain a single effective state through a static root_token which is updated through the UGI ctor as follows:
  [A] if the passed token == root_token (incl. both nulls):
      root_token remains unchanged
  [B] else (the passed token != root_token):
      root_token gets a fresh start (new gesture, new expiry deadline)

Now saved tokens have two usage patterns:
- For mouse events, a UGI is created before saving the root_token at mousedown, then the UGI gets out of scope.  The saved token is then reused to create a new UGI at mouseup; [B] implies this is like using a brand new token.  This is done in EventHandler, WebViewImpl, WebFrameWidget{Impl,Base}.

- The rest of the use-cases (DOMTimer, PostMessageTimer in LocalDOMWindow, ScheduledNavigation, SuspedableScriptExecutor) saves current root_token w/o creating one (so could be null), then reuses the saved token later on to create a new UGI.  The outcome depends on what happened to the old UGI in between: if it was destructed (with or w/o consumption), the new UGI is like a new gesture [B]; otherwise the new token is ignored [A].  This seems unpredictable.

A simple solution: don't save token, but instead save the active gesture state (if there is any unconsumed gesture), and use the state to create a UGI later on.

So we won't need any UGT!