Extract RPC typing into its own module to avoid dependencies between
the store and the RPC implementation. Clarify a few points in other
types.

Move the typing for the parameter passed to the `changeFocusModeUser`
RPC call into `cross-origin-rpc` and expand in preparation for
supporting group filtering.

Add support for normalizing a set of GroupIdentifiers (which could be
`id`s or `groupid`s or a mix) to  `id`s, for use with store layer logic.

Needed to support filtering groups based on RPC calls from the LMS
application, which sends `groupid`s.

In grading mode, a student may belong to more than one group and the
instructor may switch between groups when grading the student. Restore
the applied user-focus filter when switching groups to maintain UI
continuity.

All Group objects have an `id`, some have a `groupid`. First party
groups deal in `id`s only (aka `pubid`s), while LMS groups use
`groupid`s as they include authority information and are unique across
all authorities.

The only typical time that the filter interface is visible when loading
is when loading groups for a focused student-user in grading mode.
Other filtering happens client-side and doesn't involve loading.

But when we ARE loading, don't show an inaccurate count (because we
don't have all the results yet), show a spinner instead.

I defined a type and initialise the value of `Guest#selectedRanges` in
the constructor.

As far as I know, this is used only in tests.

Follow up of https://github.com/hypothesis/client/pull/3904/files#r764767461

The main `Guest` was assumed to be always in the same frame as the
`host` frame. In that scenario (which is currently the most common),
`Guest` was able to communicate with the `host` via `TinyEmitter`.

This PR removes that assumption an enforce all communication between the
`Guest` and the `host` to occur via an inter-frame communication
channel. This paves the work for the main `Guest` to be in a different
frame than the `host`, which is the case in the Ebook readers and
VitalSource.

Fix several issues with the Sentry file uploads which prevented Sentry
from using the uploaded files.

 - Upload the JS bundles to Sentry as well as the sourcemaps. Sentry
   reads the `sourceMappingURL` comment from the JS

 - Set the correct URL prefix for the files, so that Sentry knows that
   eg. "sidebar.bundle.js" is served at https://cdn.hypothes.is/hypothesis/$VERSION/build/scripts/sidebar.bundle.js

   For Sentry to use a file uploaded in a release, the artifact name
   (URL prefix + name) must match the URL from which it is served (and
   referenced in crash reports). The origin of the URL can optionally be
   shortened to `~`, but we haven't done that here.

 - Finalize the release after uploading files

Rewrite source paths in sourcemaps from being relative to the sourcemap
URL (eg. "../../src/path/to/file.js") to absolute URLs ("app:///src/path/to/file.js").
This ensures that the resolved source URLs, which result from joining
the sourcemap URL to the source path, remain consistent across releases.
This in turn improves issue grouping.

For a full explanation of how Sentry processes JavaScript crash
reports and determines the fingerprint used to group issues, see
https://gist.github.com/robertknight/cbdee9db50601c5244d9e483930c32ca.

Bumps [tailwindcss](https://github.com/tailwindlabs/tailwindcss) from 2.2.19 to 3.0.2.
- [Release notes](https://github.com/tailwindlabs/tailwindcss/releases)
- [Changelog](https://github.com/tailwindlabs/tailwindcss/blob/master/CHANGELOG.md)
- [Commits](https://github.com/tailwindlabs/tailwindcss/compare/v2.2.19...v3.0.2)

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

In fixing https://github.com/hypothesis/client/issues/3681, we will be
stripping parts of the script filename in stacktraces sent to Sentry. As
a result it will no longer be possible for Sentry to fetch the script
and associated sourcemap from https://cdn.hypothes.is/. Instead we need
to upload sourcemaps directly to Sentry as part of the build process.

See https://docs.sentry.io/platforms/javascript/sourcemaps/uploading/

Bumps [puppeteer](https://github.com/puppeteer/puppeteer) from 12.0.1 to 13.0.0.
- [Release notes](https://github.com/puppeteer/puppeteer/releases)
- [Changelog](https://github.com/puppeteer/puppeteer/blob/main/CHANGELOG.md)
- [Commits](https://github.com/puppeteer/puppeteer/compare/v12.0.1...v13.0.0)

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

Bumps [rollup](https://github.com/rollup/rollup) from 2.60.2 to 2.61.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.60.2...v2.61.1)

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

Bumps [postcss](https://github.com/postcss/postcss) from 8.4.4 to 8.4.5.
- [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.4...8.4.5)

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

Bumps [eslint-plugin-mocha](https://github.com/lo1tuma/eslint-plugin-mocha) from 9.0.0 to 10.0.1.
- [Release notes](https://github.com/lo1tuma/eslint-plugin-mocha/releases)
- [Changelog](https://github.com/lo1tuma/eslint-plugin-mocha/blob/master/CHANGELOG.md)
- [Commits](https://github.com/lo1tuma/eslint-plugin-mocha/compare/9.0.0...10.0.1)

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

Bumps [sass](https://github.com/sass/dart-sass) from 1.44.0 to 1.45.0.
- [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.44.0...1.45.0)

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

Bumps [preact](https://github.com/preactjs/preact) from 10.6.2 to 10.6.4.
- [Release notes](https://github.com/preactjs/preact/releases)
- [Commits](https://github.com/preactjs/preact/compare/10.6.2...10.6.4)

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

Bumps [eslint](https://github.com/eslint/eslint) from 8.4.0 to 8.4.1.
- [Release notes](https://github.com/eslint/eslint/releases)
- [Changelog](https://github.com/eslint/eslint/blob/main/CHANGELOG.md)
- [Commits](https://github.com/eslint/eslint/compare/v8.4.0...v8.4.1)

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

Bumps [dompurify](https://github.com/cure53/DOMPurify) from 2.3.3 to 2.3.4.
- [Release notes](https://github.com/cure53/DOMPurify/releases)
- [Commits](https://github.com/cure53/DOMPurify/compare/2.3.3...2.3.4)

---
updated-dependencies:
- dependency-name: dompurify
  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.15.0 to 6.16.1.
- [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.15.0...6.16.1)

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

Bumps [typescript](https://github.com/Microsoft/TypeScript) from 4.5.2 to 4.5.3.
- [Release notes](https://github.com/Microsoft/TypeScript/releases)
- [Commits](https://github.com/Microsoft/TypeScript/compare/v4.5.2...v4.5.3)

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

Bumps [aws-sdk](https://github.com/aws/aws-sdk-js) from 2.1043.0 to 2.1046.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.1043.0...v2.1046.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>

`deleteAnnotation` RPC event can be triggered before `loadAnnotations`.
This is a race condition in which annotations are asked to be deleted in
the `sidebar` frame before the `guest` frame finishes to anchor the
annotations.

B
This problem is avoided by maintaining one additional set which tracks
the annotations that should be in the page. This can be updated 1) when
an annotation is received, just before it is anchored and 2) when an
annotation is detached. After anchoring completes, the logic can check
if the annotation should still be present in the page and skip saving
the anchor if not.

Solution from here:
https://github.com/hypothesis/client/pull/4007#discussion_r763971360

🤦

After the proposal in
https://github.com/hypothesis/client/pull/4014/commits/c32b7013df49fae87adca077e571f42ef1162e7d,
we agree this alternative approach for clearing the selection on another
iframe is more straight forward.

To test this PR:

1. Go to http://localhost:3000/document/cross-origin-iframe
2. Make a text selection in one frame. The adder should appear
3. Make a text selection in the other frame. The adder should appear.
   The adder in the other frame should disappear _and_ the selection
   should be removed.

There was a difference in behaviour when creating an annotation using
the `Adder` vs. using the `New annotation` button in the sidebar:

* clicking on the adder's `Annotation` button made the adder disappears.

* clicking on the sidebar's `New Annotation` didn't hide the adder.

This PR makes the adder to disappears when `New Annotation` button is
pressed.

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

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

In order to toggle correctly the `Toolbar` button between `New page
note` and `New annotation` we have created a new `guest-host` channel of
communication. Previous code failed to toggle the button because it used
an event emitter, hence assuming that the `Guest` was in the same frame
as the host.

- The `Sidebar` keeps track of the iframe that has currently text
  selected. It uses the `subFrameIdentifier`. If there is no
  `subFrameIdentifier` (currently the top `Guest` frame), it sets the
  identifier to 'main', referring to the frame with the main annotatable
  content. This will change in a follow up PR that will add more logic
  into which frame is tagged as 'main'.

- Only one iframe at a time can have selected text.

- The event emitter `hasSelectionChanged` has been replaced by three RPC
  methods: 'textSelectedAt`, 'textDeselectedAt', 'deselecTextExcept'

- `deselecTextExcept` is used to clear text selections in other frames,
  except from the iframe that has the latest selection. This is not the
  neatest solution, but for now it works.

On a follow up PR I will address the removal of the shadow left from
previous a selection.

Closes https://github.com/hypothesis/product-backlog/issues/1236

To help us debug issues with sidebar-host connection setup [1], report an
error to the sidebar if PortProvider receives a message which looks like
a port request (data has the structure `{ frame1: string, frame2:
string, type: 'request' }`) but comes from a non-Window source, invalid
origin or is not a valid combination of frames.

[1] https://sentry.io/organizations/hypothesis/issues/2810452318/

When a guest frame with an opaque origin, such as file:// URL or a sandboxed
iframe, sends a request for a port to the host frame, the `event.origin` value
will be the string "null". This is not a legal value for the `targetOrigin`
argument to `postMessage`, so we need to remap it to "*" (any origin).

Dates are in fact JSON-serializable, but as strings.

Recent changes to `isMessageEqual` mean that the `JSON.stringify` calls
cannot fail, because the `isMessage` check ensures all the fields we
serialize are strings. Writing a test to check for this failure mode is
not possible. There is a refactoring hazard here, so I added a comment
to call this out.