Add WebPush Topics

[bbangert]

This will require a new keying scheme for the DynamoDB sort key. Right now the sort key is:

chidmessageid - CHID : Encrypted(UAID : CHID)

This also means that our messages are in arbitrary orders on retrieval.

There are some constraints on keys to consider:

1. Keys shouldn't be too long, as they need to be sent to/from the client for every message
2. We must be able to locate a message of a given topic for delete/replacement. Ideally we can replace any existing message of the same topic to avoid 2 writes per Topic'd message (as a delete counts as a write).
3. Migration from the existing sort key scheme must be transparent.

A proposed scheme for sort keys originally failed to account for the need to possibly DELETE the message. Here's a new scheme that might work:

For topic messages only:

VERSION : CHID : HASH(TOPIC)

When a topic-bound message is created, we create a URL resource for a Location like so:

Encrypted(VERSION : UAID: CHID : HASH(TOPIC))

This is stored as the update_id for the message. Since we use a nonce-based crypto scheme, it changes every time we update it (as desired to reflect new resource creation). We can also locate the message, and ensure the update_id matches before deleting it.

For normal messages:

VERSION: CHID: Encrypted(VERSION : UAID : CHID)

Note that we must now include the VERSION so we know when we're using the newly versioned token scheme.

[jrconlin]

r=

Follow up from local discussion, the topic is only 32 char of ASCII, file name safe text, so simple hashes are preferred. This does not need to be secure, only unique, so compressed sampling is an option. This shouldn't add too much to the increasing URL length.

[ghost]

It's also URL-safe Base64, so we don't need to worry about spaces or special characters besides - and _. Probably OK not to hash.

[bbangert]

It has since come up that we need to avoid delete calls in the future, so the key scheme needs to be compatible with the ability to seek into a position. Unfortunately topics are incompatible with this as they require a known and consistent key to be locateable in the db. So topic messages will always require deletion (but there should be less of them to delete since they replace prior ones).