The new built-in "connect" PortRPC event (see #4175) makes the `ready`
RPC event redundant. The host frame now uses the `connect` event to know
when the sidebar frame is connected, and hence display it.

 - Use asserts to verify that "close" events are not emitted earlier
   than they should be, rather than blindly resetting the close event
   listener stub.
 - Reset the sinon sandbox after each test to ensure any DOM APIs are
   unmocked

Add two built-in events to PortRPC which are dispatched when PortRPC connects to
a port and when it is destroyed or the containing frame is unloaded. These
events can be used in the counterpart PortRPC to confirm that the sender has
successfully received and connected to the port, and to get notified when the
port goes away.

Sending the "close" event in the context of a window unloading in Safari
<= 15 requires a workaround that involves registering a handler in the
parent frame. This handler is currently installed only in the host frame.

The new "close" event is used to replace the "frameDestroyed" message
that was used by guests to notify the sidebar when it went away. This solves
several problems:

 - It centralizes the workaround for https://bugs.webkit.org/show_bug.cgi?id=231167
   in `post-rpc.js`, instead of having it spread between several
   modules.

 - It provides a way to tear down the guest-host connection when the
   guest goes away.

 - It provides a way to handle the case where a guest is unloaded before it
   has received and connected to the port, by having the host/sidebar frames
   expect the "connect" call within a timeout. This is not yet implemented.

Since all message types now include this property, we can check for it
in `isMessage` instead of requiring a separate check.

PortProvider previously used a `WeakMap<Window, Set<Channel>>` to keep
track of which ports had been requested from a particular source frame,
where the map keys came from `MessageEvent.source`. A problem with this
approach is that for messages from an iframe, `MessageEvent.source` refers to a
`WindowProxy` which retains the same identity across page navigations.
As a result if a guest iframe was navigated to a new page which also
embedded the client as a guest (or into which the client was
subsequently injected as a guest), the guest in the new document would
not be able to retrieve any ports.

Implement a fix whereby each call to `PortFinder.discover` generates a
random request ID which is sent with the initial port request plus any
re-sent requests. PortProvider then keeps track of the request IDs it
has seen and ignores messages with a previously seen request ID.

This change would also fix port discovery if the guest in a frame was
unloaded and later re-loaded.

Bumps [postcss](https://github.com/postcss/postcss) from 8.4.5 to 8.4.6.
- [Release notes](https://github.com/postcss/postcss/releases)
- [Changelog](https://github.com/postcss/postcss/blob/main/CHANGELOG.md)
- [Commits](https://github.com/postcss/postcss/compare/8.4.5...8.4.6)

---
updated-dependencies:
- dependency-name: postcss
  dependency-type: direct:development
  update-type: version-update:semver-patch
...
Signed-off-by: dependabot[bot] <support@github.com>

Bumps [axe-core](https://github.com/dequelabs/axe-core) from 4.3.5 to 4.4.1.
- [Release notes](https://github.com/dequelabs/axe-core/releases)
- [Changelog](https://github.com/dequelabs/axe-core/blob/develop/CHANGELOG.md)
- [Commits](https://github.com/dequelabs/axe-core/compare/v4.3.5...v4.4.1)

---
updated-dependencies:
- dependency-name: axe-core
  dependency-type: direct:development
  update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>

Bumps [karma](https://github.com/karma-runner/karma) from 6.3.12 to 6.3.15.
- [Release notes](https://github.com/karma-runner/karma/releases)
- [Changelog](https://github.com/karma-runner/karma/blob/master/CHANGELOG.md)
- [Commits](https://github.com/karma-runner/karma/compare/v6.3.12...v6.3.15)

---
updated-dependencies:
- dependency-name: karma
  dependency-type: direct:development
  update-type: version-update:semver-patch
...
Signed-off-by: dependabot[bot] <support@github.com>

Bumps [core-js](https://github.com/zloirock/core-js) from 3.20.3 to 3.21.0.
- [Release notes](https://github.com/zloirock/core-js/releases)
- [Changelog](https://github.com/zloirock/core-js/blob/master/CHANGELOG.md)
- [Commits](https://github.com/zloirock/core-js/compare/v3.20.3...v3.21.0)

---
updated-dependencies:
- dependency-name: core-js
  dependency-type: direct:development
  update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>

Bumps [aws-sdk](https://github.com/aws/aws-sdk-js) from 2.1066.0 to 2.1069.0.
- [Release notes](https://github.com/aws/aws-sdk-js/releases)
- [Changelog](https://github.com/aws/aws-sdk-js/blob/master/CHANGELOG.md)
- [Commits](https://github.com/aws/aws-sdk-js/compare/v2.1066.0...v2.1069.0)

---
updated-dependencies:
- dependency-name: aws-sdk
  dependency-type: direct:development
  update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>

Bumps [sass](https://github.com/sass/dart-sass) from 1.49.0 to 1.49.7.
- [Release notes](https://github.com/sass/dart-sass/releases)
- [Changelog](https://github.com/sass/dart-sass/blob/main/CHANGELOG.md)
- [Commits](https://github.com/sass/dart-sass/compare/1.49.0...1.49.7)

---
updated-dependencies:
- dependency-name: sass
  dependency-type: direct:development
  update-type: version-update:semver-patch
...
Signed-off-by: dependabot[bot] <support@github.com>

Bumps [@sentry/browser](https://github.com/getsentry/sentry-javascript) from 6.17.3 to 6.17.4.
- [Release notes](https://github.com/getsentry/sentry-javascript/releases)
- [Changelog](https://github.com/getsentry/sentry-javascript/blob/master/CHANGELOG.md)
- [Commits](https://github.com/getsentry/sentry-javascript/compare/6.17.3...6.17.4)

---
updated-dependencies:
- dependency-name: "@sentry/browser"
  dependency-type: direct:development
  update-type: version-update:semver-patch
...
Signed-off-by: dependabot[bot] <support@github.com>

Bumps [sinon](https://github.com/sinonjs/sinon) from 13.0.0 to 13.0.1.
- [Release notes](https://github.com/sinonjs/sinon/releases)
- [Changelog](https://github.com/sinonjs/sinon/blob/master/docs/changelog.md)
- [Commits](https://github.com/sinonjs/sinon/compare/v13.0.0...v13.0.1)

---
updated-dependencies:
- dependency-name: sinon
  dependency-type: direct:development
  update-type: version-update:semver-patch
...
Signed-off-by: dependabot[bot] <support@github.com>

Bumps [@babel/core](https://github.com/babel/babel/tree/HEAD/packages/babel-core) from 7.16.12 to 7.17.0.
- [Release notes](https://github.com/babel/babel/releases)
- [Changelog](https://github.com/babel/babel/blob/main/CHANGELOG.md)
- [Commits](https://github.com/babel/babel/commits/v7.17.0/packages/babel-core)

---
updated-dependencies:
- dependency-name: "@babel/core"
  dependency-type: direct:development
  update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>

Bumps [rollup](https://github.com/rollup/rollup) from 2.66.1 to 2.67.1.
- [Release notes](https://github.com/rollup/rollup/releases)
- [Changelog](https://github.com/rollup/rollup/blob/master/CHANGELOG.md)
- [Commits](https://github.com/rollup/rollup/compare/v2.66.1...v2.67.1)

---
updated-dependencies:
- dependency-name: rollup
  dependency-type: direct:development
  update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>

Background information

Currently, the bucket-bar should display anchor positions only from a
_single_ guest frame. This is because there is no merging mechanism for
anchor positions from multiple guest frames.

Before this PR

* The host frame listened for `anchorsChanged` events from
_all_ the guest frames.

* Only _one_ guest frame sent this event. We referred to this guest
  frame as having the 'main' annotatable content.  The 'main'
  annotatable guest frame was identified by not having a
  `subFrameIdentifier` (a configuration option added to a guest frame
  when the Hypothesis client was injected). Hence, the 'main'
  annotatable guest frame was always the frame where the Hypothesis
  loaded initially (in contrast with the injection mechanism).

In this PR

We have reversed the logic of how the `anchorChanged` RPC
events are send and received:

* _Every_ guest frame sends `anchorsChanged` RPC events to the host
  frame.

* The host frame chooses to listen to only _one_ guest frame for the
  `anchorsChanged` RPC events: the guest frame that connects first with
  the host.

For non-VitalSource case, the first guest frame that connects to the
host frame is the one where the Hypothesis client was initially loaded
(doesn't contain `subFrameIdentifier` option).

For the VitalSource, because of #4176, there is no guest frame in the
host frame. This allows the guest frame in the book content, where the
Hypothesis client was injected, to send anchor positions, and positions
to be reflected in the host's bucket-bar.

On #4069, we introduced a small improvement when hovering a left-pointed
bucket: focus the corresponding annotation card, in addition to the
anchor's highlight.

In this PR, we introduce the same improvement to the up and down-pointed
buckets.

In addition, I have realised we handled `onBlur` but not `onFocus`
events. I have added more complete support for keyboard navigation.

I substituted `onMouseMove` for `onMouseEnter` because it is triggered
less frequently.

Co-authored-by: Robert Knight <robertknight@gmail.com>

In order to not create an unnecessary `Guest` instance in the
VitalSource container we needed to do the following:

* The `VitalSourceContainerIntegration` is stripped down and converted
  to a class, `VitalSourceInjector`, that does not implement the
  Integration interface but is only responsible for injecting the client
  into content frames.

* The host frame checks the VS frame role and either constructs a Guest
  or sets up the `VitalSourceInjector` as appropriate.

* The `HypothesisInjector`-related logic in `Guest` is extracted out of
  that class and set up in the annotator entry point instead.

Refactor applied design and layout for ModerationBanner to fix
regressions and bring component into more standard design patterns.

To allow for proper alignment of child elements using `rem` units,
adjust a couple of outer padding values for `Thread` and `ThreadCard`

Later we will convert `Thread` and `ThreadCard` to `rem`s and tailwind,
but that is a separate task.

When the sidebar is connected to multiple guest frames it will send all
incoming annotations to all frames. The result is typically that the
annotation will anchor in one frame and orphan in the others. Depending
on what order this happens in, the annotation will non-deterministically
show up as an Annotation or Orphan in the sidebar.

In order to determine which frames an annotation should be sent to in
all cases, we'd either need the backend to return information about which
search URIs an annotation matches or make a separate search request for
each frame and record the associated frame with the results. This
will require some significant refactoring of the annotation search
service.

As an interim step, make `FrameSyncService` send annotations only to a
single frame based on matching URL, with a fallback to sending to the
main frame if there is no exact match. This will work as expected for
most pages, and is at least deterministic when it does fail. When we
have a solution for being able to match annotations to frames more
generally, we can adapt this code to use it.

This is a partial solution to https://github.com/hypothesis/client/issues/3992.

Change how the guest notifies other frames, specifically the sidebar and host,
when it is unloaded. The host and sidebar now receive a `frameDestroyed` message
from the corresponding guest port, which allows them to easily close the right
port and remove it from the list of active guest ports.

Due to a Safari bug (see code comments) we can't send the `frameDestroyed`
messages from the guest frame while it is being unloaded. However it is possible
to first transfer the port to the host frame and then have the host frame send
the message on the same port. I also tried sending the message from the guest
frame, and then transferring the port to the host frame but that didn't work.
This workaround has the advantage that it is transparent to the receiver of the
`frameDestroyed` message.

This change is also a step towards possibly not relying on user-provided guest
frame identifiers in the sidebar, which only become available once the
`documentInfoChanged` call has been received. Instead the sidebar could
use its own internal IDs for guest frames, avoiding the possibility for
conflicts.

Changes in detail:

 - Add `disconnect` method to PortRPC

 - When guest is unloaded, transfer ports to the host frame in a
   `hypothesisGuestUnloaded` message, and make the host frame dispatch
   `frameDestroyed` calls on these ports.

 - Handle `frameDestroyed` in sidebar by closing port, removing it from
   the active guest list and removing the associated frame from the
   store

 - Handle `frameDestroyed` in host frame by closing port and removing it
   from the active guest list

Unless the actual name is really verbose or conflicts with another variable, we prefer to avoid import aliases.