I'm about to use this in a calculation elsewhere.

Make annotation directive more consistent with other directives

 * Make it an element directive and use the existing utility
   functions for instantiating them in tests
 * Use '=' bindings for input properties and 'on<EventName>' names
   for events
 * Remove unused 'showReplyCount' input property and the
   shouldShowNumReplies() function which was only used
   as the argument to this property.

Don't crash out if username blacklist doesn't load

Frontend cleanups

Fix reply notification worker

These files were converted from CoffeeScript and 'use strict'
was never added.

This removes the use of compass mixins for transition
properties, where the mixin was used for vendor prefixing,
a problem now solved by autoprefixer.

This enables the sidebar app to function with only
jQLite, rather than the full jQuery library.

The main differences are:

 - jqLite's find() method only supports tag names.
   Element.querySelector() can be used instead
 - jqLite-wrapped input elements do not have a focus()
   method. Just call focus() on the input instead
 - The DOM focus() and select() methods are not fluent
   like their jQuery counterparts

Add developer API tokens

Add a /profile/developer/ page where users can generate and re-generate
their API token. This token can be used as a Bearer token in the
Authorization header in API requests instead of using one of the more
complex and short-lived JWT tokens that the client uses to authenticate
API requests.

The tokens are just randomly generated opaque strings, each one
associated with one user account. There's 0 or 1 token per user, and the
user can regenerate their token at any time. The tokens are stored in a
`token` table in the db that just maps token values to userids.

Notes:

- Our authentication policy now calls the new API token validator first
  for API requests. If this validator does not accept the token, then it
  passes it to the legacy JWT validator (which is still used by our
  client).

  The idea is that if we add more types of API token in the future, the
  authentication policy will have a list of different validator
  functions for different token types, and will try each validator in
  turn until either one of them accepts the token or it runs out of
  validators.

  The use of a type prefix string at the beginning of tokens means that
  validators can usually reject tokens without a db lookup, so we won't
  end up with one db lookup per validator.

- The new tokens always start with u"6879-". If a token sent by a user
  doesn't start with this prefix then the token validator can reject it
  out of hand, without doing a database lookup.

  An opaque number is used for this prefix because we want users to
  treat API tokens as opaque, rather than using a human-readable prefix
  that makes it obvious what type of token you're looking at. (But the type
  of the token is not "secret" in any real sense.)

  In the future it's intended that we'll have different types of tokens
  identified by different prefixes, and different types of token might
  (for example) give access to different capabilities.

- The legacy JWT tokens (still used by our own client) do not have any
  such prefix. If all other token validators (currently just the one new
  API tokens validator) reject a token, then the auth policy will fall
  back to the legacy JWT token validator.

  I think it might be possible that a JWT by random chance could begin
  with u"6879-". If that happens then the new API tokens validator would
  not reject the token based on its prefix and would do a db lookup, but
  the lookup would return nothing and the validator would then reject
  the token, and the auth policy would then move on to the legacy JWT
  validator which would accept the token. So it would be okay.

- There's no foreign key constraint from the token table's userid column
  to the user table, because the user table belongs to the app whereas
  the token table belongs to the api.

Postgres annotations

Fix broken promises in IE

Fixes #2953.

We support IE10/11, neither of which define Promise globals, so make
jshint warn if we use Promise without explicitly defining it (by
importing a polyfill).

Fix #2810: no error on sign in to unactivated account

Finish indirection through storage

Simpler version management

Mark deployed features as pending for removal

I broke this in f7b519d, it seems.

Fix RavenJS initialization in app and stream

Improve Chrome sidebar injection error detection and handling

Improve capture of sidebar injection errors

Put the Error first as the most important argument, followed
by a string describing when the error happened, followed by optional
context information.

This also reduces unnecessary nesting in the 'extra' field
of the captured exception that is sent to Sentry.

app.coffee failed to initialize Raven because it looked for
config info in window.RAVEN_CONFIG instead of the #hypothesis-settings
<script> tag.

This commit makes the web service expose the Raven config info
to the site and the application in the same way, using JSON <script>
tags which are compatible with the strict CSP policy used by
the Chrome extension.

 * Expose and consume config info in the same way on
   the site and in the app.

 * Refactor settings.js to make it independent of Angular, for
   use on the site.

Fixes #2938

 * Capture the tab URL as context when injecting the sidebar
   fails, for use in debugging.

 * Switch tests to use the toResult() helper instead of
   Promise.catch() to handle assert errors inside
   catch blocks properly.

 * Handle the Error-like objects used by chrome.extension.lastError
   better.

   When a Chrome async API fails, it sets chrome.extension.lastError
   to an Error-like object with a 'message' property. Since this
   object is not an instance of Error, RavenJS stringified it
   with .toString(), resulting in an unhelpful '[object Object]'
   message in Sentry.

   This commit adds logic to extract out the message property
   of such objects when capturing exceptions.

Merge pull request #2929 from hypothesis/2928-restore-counting-of-private-and-group-annotations-in-badge

Restore counting of private and group annotations in badge

Specify the minimum Chrome version in the manifest

Fix base URL not being specified for /app/dismiss_sidebar_tutorial route

Simplify server side auth code

Add a PENDING_REMOVAL bucket for features on their way out

The dismiss_sidebar_tutorial session action overrode the whole
URL, including replacing the base URL with just '/app'. Therefore
it would have failed when app.html's origin did not match the service
URL - as in the Chrome extension.

 * Pass the complete URL for the dismiss_sidebar_tutorial action

 * Remove several unused actions from session.js that have been
   replaced by server-rendered forms

 * Add test for dimiss_sidebar_tutorial action

Add automated retry with backoff for session loads

Always count annotations with the correct userid

Don't autofocus the group share link

Unfortunately, on group pages for groups who have annotated lots of
documents, this results in a rather confusing jump to the bottom of the
page.

Fixes #2917.

If a session load fails, subsequent calls to
session.load() would trigger another request immediately.
Together with feature flag checks triggering session.load(),
this could result in a cycle if no network connection was present:

 1. App loads during initial digest cycle, 'flag.featureEnabled()'
    is called to test whether to show certain UI elements
 2. session.load() is triggered
 3. session.load() fails and the HTTP response error triggers
    a digest cycle
 4. GOTO 1

This commit resolves the problem by automatically retrying
session.load() calls with an exponential backoff.