When the `adder` is hidden reposition the outer container to the
top-left corner of the host page.

Add a PDF document link on the dev server homepage which uses a URL that
has a random suffix parameter added on page load and each time the link
is clicked.

This is useful for testing the behavior of client features (eg.
annotation fetch and real time updates) which should show the same
content/notifications etc. across copies of the "same" document
presented at different URLs.

This will aid with testing changes such as https://github.com/hypothesis/h/pull/6542.

This changes the sorting in the notebook to sort by date created rather than last edited date ("updated"). This prevents root threads from resorting to the top after they are edited in the notebook.  This also changes the way the sidebar orders root threads when using Newest/Oldest sorting filter in the same manner.

`Notebook` and `Sidebar` components create `<hypothesis-...>` elements
that attach shadow DOMs. This PR makes the `Adder` class responsible of
creating its own outer element.

While there is no mechanism to sync new annotations in the notebook, we
force re-rendering of the iframe on every 'openNotebook' event, so we
fetch the new annotations.

This is a temporary fix that is intended to be removed.

Add some pattern structure to the playground app and a
placeholder "Menu" demo

Added a11y tests to these components:

- NotebookView
- FilterSelect
- NotebookResultCount
- PaginationNavigation

To following components I didn't add a11y tests because they are
wrappers of one or several components already tested:

- PaginatedThreadList (ThreadList + PaginationNavigation)
- NotebookFilters (FilterSelect)

This ensures that GitHub Actions checks run for PRs submitted from forks,
which includes all PRs submitted by people outside the Hypothesis
organization.

Note that this change which commit the checks run on. See [1] for
details.

This change also matches how GitHub CI is set up in other projects (eg.
lms, h).

[1] https://docs.github.com/en/actions/reference/events-that-trigger-workflows#pull_request

Bumps [aws-sdk](https://github.com/aws/aws-sdk-js) from 2.863.0 to 2.868.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.863.0...v2.868.0)
Signed-off-by: dependabot[bot] <support@github.com>

Bumps [@sentry/browser](https://github.com/getsentry/sentry-javascript) from 6.2.2 to 6.2.3.
- [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.2.2...6.2.3)
Signed-off-by: dependabot[bot] <support@github.com>

Bumps [postcss-url](https://github.com/postcss/postcss-url) from 10.1.1 to 10.1.3.
- [Release notes](https://github.com/postcss/postcss-url/releases)
- [Changelog](https://github.com/postcss/postcss-url/blob/master/CHANGELOG.md)
- [Commits](https://github.com/postcss/postcss-url/compare/10.1.1...10.1.3)
Signed-off-by: dependabot[bot] <support@github.com>

Bumps [terser](https://github.com/terser/terser) from 5.6.0 to 5.6.1.
- [Release notes](https://github.com/terser/terser/releases)
- [Changelog](https://github.com/terser/terser/blob/master/CHANGELOG.md)
- [Commits](https://github.com/terser/terser/commits)
Signed-off-by: dependabot[bot] <support@github.com>

Bumps [commander](https://github.com/tj/commander.js) from 7.1.0 to 7.2.0.
- [Release notes](https://github.com/tj/commander.js/releases)
- [Changelog](https://github.com/tj/commander.js/blob/master/CHANGELOG.md)
- [Commits](https://github.com/tj/commander.js/compare/v7.1.0...v7.2.0)
Signed-off-by: dependabot[bot] <support@github.com>

We have had Google Analytics disabled for the Hypothesis client for over
a year and do not plan to re-enable it. We may need analytics for other
purposes in future (for example, to help inform product design). In that
case we will likely implement a solution that is a better fit for
whatever those needs end up being.

This commit removes the existing analytics code in the meantime so that
we don't spend time maintaining something that is not used.

Fixes #3027

Display a visual error message if fetching the client's configuration fails,
eg. due to a failure to fetch a grant token in the LMS app.

Notebook class creates the container element and instantiates the preact
component NotebookModal.

NotebookModal listens to the openNotebook event sent through the
eventBus and hides and shows the modal accordingly.

The creation of the iframe is a costly operation: it involves several
backend calls and the rendering of it in the DOM. Therefore, we delay
the creation of the iframe element until the NotebookModal listens for
the `openNotebook` event.

The useEffect's cleanup of the NotebookModal componente has significant
effects because it resets the overflow CSS property of document.body.

As pointed by @robertknight, `render(null, container)` destroys the
component triggering the useEffect's cleanup function.

Emit a `ResultSizeError` when encountering too many annotations to load.
Update `NotebookView` to display a message when this happens.

Add a basic Panel component to be used by `SidebarPanel` and for
other basic panel-y needs.

We have done a little investigation on the number of threads that are
visible on a pages in notebook:
- on mobile: up to 4 threads
- on tables: up to 7 threads
- on mobile: up to 8 threads

These numbers are just rough estimates since zoom level and screen
orientation affects these numbers.

Our aim: we want to display the larger number of threads without forcing
users to do excessive scrolling.

We are going to test with 25 threads per page and see what are users
think about that.

Per PR feedback, rename the `pageSize` option to something that sounds more like a
function/callback, which is what this value now is.

When fetching annotations from the backend there is a trade-off between
the time taken to generate a page (less if the page size is smaller) and
the time taken to fetch all pages (less if the page size is larger).

To optimize the perceived loading time we can pick a smaller page size
for the first page, enabling the first screenful of annotations/threads
to appear quickly, and then use a larger page size for the remaining
pages.

 - Change the `pageSize` option for `SearchClient` from a fixed number
   to a callback that returns the page size for a given page index

 - Set the default value for the `pageSize` option to use a small page
   size (50) for the first page and a larger size (200) for remaining
   pages

Consistently use the term "page" to refer to a subset of results fetched
from the search API instead of "batch" or "chunk". This is more
consistent within the rest of the client code and also consistent with
the API documentation.

 - Rename `chunkSize` constructor argument to `pageSize`
 - Change internal references to "batch" or "chunk" in SearchClient to
   "page"

Reordered fields according to the UI and capitalised properties.

I have tested successfully on the latest version of Chrome, Safari and
Firefox. I also tested successfully on an Android and iOS devices.

I couldn't tested more exhaustively on other desktop/mobile browser
versions because SauceLabs didn't allowed me to retrieve the pasted
text.

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

Reword this comment to try and make the intent of the code clearer.

It is safe to call `load` while annotations are already being loaded,
in that it does all the necessary cleanup/interruption of the existing
fetch. However it wasn't immediately clear to me from the code that this
was the case.

Currently both the sidebar and notebook wait until the user's profile and groups are
fetched before fetching annotations. This is because the search query to
fetch annotations depends on the focused group. The groups query may
take several hundred ms to complete, so this ends up delaying the
initial fetch and display of annotations by that amount of time.

In the notebook the common case is that the user is already logged in
and the notebook is configured to display a specific group ("the direct
linked group"): whatever the user had previously selected in the sidebar.
In this scenario it is very likely that the direct-linked group will end
up being the focused one after groups are fetched.

Based on these assumptions, we can speed up the initial annotation by
loading annotations from the direct-linked group. If the focused group
ends up being different, annotations will just be re-fetched from the
correct group once that is known.

 - Remove unused references to `offset` search query param
 - Add JSDoc to clarify what the `searchAfter` param is

- Add an additional test that checks the query params sent for each of the
  pages sent for a simple single-URI query.

- Refactor the remaining SearchClient tests which still use
  promise-chains to use async/await instead for readability and
  consistency

Optimize fetching pages of results from the backend by using
cursor-based paging (via `search_after`) rather than offset-based paging
(via `offset`, `limit`). Cursor-based paging is more efficient to handle in
the backend as the starting position of a page within the overall result set increases.

This also fixes a race condition where results at the boundary between
pages might be fetched twice or not fetched if new matches for the query
become available while results are fetched.