HTML's user activation modes don't work for us

[martinthomson]

A simple text confirms that our understanding of how activation works doesn't fit our requirement:

One page has a link:

<a href="the-other.html">Click</a>

The other page reports whether it receives activation:

<script>window.alert(`is ${navigator.userActivation.isActive} was ${navigator.userActivation.hasBeenActive}`)</script>

Spoiler: no activation on the second page, because activation is tracked on the Window. This should have been obvious to me (mea culpa), but I didn't read the spec closely enough.

Aside: Why browsers let sites use window.alert() without user activation is a thing from history: it should consume activation, but doing that would break things.

So, given that this doesn't work, what do we need to do is:

1. Track activation at the "top-level traversable". In simpler terms, this is a browser tab.
2. Replicate the activation notification logic that the existing user activation logic does: On an activation-triggering input event, set some state on the navigable.
3. Decide on what state we track. If we want a single use of the API per activation, this can be a timestamp, just like for transient activation. If we want more uses of the API, this needs to include a counter, or even a set that tracks which sites were able to use the API.

Then we need to use the information. If it is just one use per activation, we can clear a timestamp, just like for transient activation. Otherwise, it gets more complicated, but clearing the timestamp is probably a good part of any option.

We also need to decide how long to keep that state active, but I suggest that we rely on the browser's already-defined transient activation duration.

---

The other part of this is to consider the role of user navigation involvement).

I'm going to suggest that we consider this in our assessment. If the site that receives activation is not the same as the current site, and user navigation involvement is "none", then maybe we can throw.

The reason I say that is that navigation that is not the result of user action should not carry this state forward. We can maybe track the site where the activation occurred and check that against the site where the API is invoked so that same-site automated navigations are OK.

However, for this part, I need to confirm that the navigation involvement is preserved across redirects. More work is needed there.

Also, it's possible that I'm overthinking this part.

---

In the interest of making progress, I am going to suggest we move ahead with #309, acknowledging that this part is buggy in its current form. That is, we don't insist that #309 "works" before landing it. There are lots of other parts to that PR that are useful.

I'm going to hazard a guess and say that this fix doesn't require a bunch of discussion, because most of what we've been talking about was operating on the assumption that it is consistent with what we've discussed.