[Contextual Search] Revive 4 tests in ContextualSearchCriticalTest (redux).

This CL relands crrev.com/4637353 (reverted by crrev.com/4650737) while
incorporating crrev.com/4649959 and fixing the flake that caused the
revert.

The 4 disabled tests in ContextualSearchCriticalTest
  testChainedSearchCreatesNewContent
  testChainedSearchLoadsCorrectSearchTerm
  testChainedSearchContentVisibility
  testChainedTapsRemovedFromHistory

are the tests that make multiple calls to simulate{Non}ResolveSearch(),
i.e., try to open the panel when it is already open (peeked). For these
tests, 3 causes for failures were found:
 1. "Space issue": TapFarFromPreviousSuppression suppresses clicks that
    are >75 dp (see RETAP_DISTANCE_SQUARED_DP) away from the previous
    click. In test case with "Search Term Resolution", growing screen
    resolutions have made "Search" and "Resolution" so distant the
    suppression engages. Apparently this was perceived as a flake, and
    retryPanelBarInteractions() -- which makes more clicks -- was added
    to mitigate it. When combined with (2), (1) triggers assert failure:

Caused by: org.chromium.base.test.util.CriteriaNotSatisfiedException:
     Expected: is "Resolution"
     but: was null

    This issue affects:
      testChainedSearchLoadsCorrectSearchTerm_
      testChainedSearchContentVisibility

 2. "Time issue": ContextualSearchInstrumentationBase.clickWordNode()
    clicks on node#search, waits for the panel to peek, then clicks on
    node#resolution. However, the wait exits quickly because the panel
    is already peeked from the earlier click. This breaks the callers
    trigger{Non}Resolve(), which rely on the wait to temporarily tweak
    "decided" to a provided value. In particular, the non-resolved flow
    (tweak to false) on "Resolution" would behave as the resolved flow,
    leading to assertion errors from |mFakeServer.getLoadedUrlCount()|
    returning the wrong value.

 3. ContextualSearchInstrumentationBase.swipePanelDown() is not robust,
    and swipes sometimes to fail to transit ContextualSearchPanel state
    from EXPANDED to PEEKED. This in turn seems to be caused by passing
    to swipe() |stepCount| = 100, which is too small.

This CL fixes the above, and revives the 4 tests.
* For (1): The earlier de-flaking attempt merely masks the problem: The
  first (suppressed) click closes the panel, and the second reopens it.
  (instead of being a tap-near). The solution:
  * tap_test.html: For text "Search Term Resolution", wrap "Resolution"
    to next line to bring node#resolution closer to node#search.
  * Add testSeparateSearchContentVisibility, which is same as
    testChainedSearchContentVisibility except it closes the Panel before
    clicking node#resolution. By comparison, this test is helpful in
    hinting whether tap-near suppression is causing problems. It's also
    much simpler than alternatives (i.e., dedicated distance test, or
    disabling tap suppression).
  * Remove retryPanelBarInteractions() and its usage, since it's no
    longer needed for the bug. There's some risk that the removal can
    expose other flakes -- we'll address these if they show up.
  * Note that we didn't increase RETAP_DISTANCE_SQUARED_DP = 75 ** 2,
    which is likely now too small. A general solution would be to adjust
    this based on screen resolution. It's unclear whether this is worth
    the effort though.

* For (2): Fix trigger{Non}Resolve() to wait for a "fresh" panel peek
  by ignoring an existing one. Ultimately this detects a fresh call to
  OverlayPanel.peekPanel(). Ideally we'd use an observer, but since the
  testing framework uses polling and delays, so a simple time-based
  solution is used:
  * Have OverlayPanel store |mLastPeekSequence|, incremented on each
    peekPanel() call, and accessed via getLastPeekSequence().
  * In ContextualSearchInstrumentationBase, add
    waitForPanelToFreshlyPeek(), which is waitForPanelToPeek() that also
    waits for getLastPeekSequence() to change.
  * Change clickWordNode() to use waitForPanelToFreshlyPeek().

* For (3): Increase |stepCount| from 100 to 1000. This drastically
  reduced the occurrence of flakes.

Bug: 1192285, 1333161
Change-Id: I0a63b4fdcb437c4970c526e837196149bab666c2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4653255
Reviewed-by: Gang Wu <gangwu@chromium.org>
Commit-Queue: Samuel Huang <huangs@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1171286}