Safe passing of trips between clients works by keeping a list of unsent
messages in each User and updating a user after login.

At least needs a mechanism to update only after sufficient time, e.g. by
adding a last-updated slot to Users.

Even better probably: add last-updated slot to user AND a
registration-time slot to trips. At login, only those trips registered
at a later time than the update time are re-sent. On confirmation, the
update time is set to the trip registration time (or later if it was
already later)
Entities:

   User:
     - email (key, a string)
     - nickname (a string)
     - last-updated (a java.util.Date)
     - pending (a map of [message-id message-content] entries)

   Trip:
     - trip-id (key)
     - owner (email)
     - mode ("offering" or "searching")
     - Arrival date and time
     - start location
     - end location 

Flow:

I. Initialization phase

   - When a user connects, he posts a /get_channel_token.
   - The server checks if there already is a token for that user.
     If not, one is created (function get-channel-token).
   - On receiving the token, the client does a "GET token_received".
   - The server in turn calls user/update_user, so that all pending 
     (unconfirmed) messages are re-sent to the user

II. Running phase

   - Whenever the user saves a new trip (route /new_trip), it is
     sent to all owners of matching trips (as returned by
     trip/find-matches) with a call to user/send-message.
   - This function adds a msg-id to the message, adds it to the
     user's pending messages, and sends it to the user.
   - Upon reception, the client posts a confirmation with the
     msg-id
   - When the confirmation is received by the server, the message
     is removed from the user's pending messages.
   - Updates (i.e. re-sending pending messages) not only occur
     whenever a get_channel_token is posted, but also when the
     user has not confirmed a message after 60 second.

This setup is perhaps a bit complicated but it guarantees that
messages to users are re-send until confirmed, and that whenever
a user goes off-line for some time and logs in again, he gets all
messages he would have received otherwise.

To do/think about:

- Change location and date/time properties in Trip to location
  and date objects

- Improve trip matching (the only filter applied to trips now is
  that they should be of different mode, so that searches are
  only sent to offers and vice versa.)

- The messages sent are now simply trips. This makes no sense if
  we stick to the model that messages are sent for each trip
  because then the same message (trip) is simply sent multiple
  times. So either we sent a trip only once to a user (requiring
  more work on the client side) or we also sent the trip to which
  the new trip matched.

- (Related) Unconfirmed messages are kept for all users. If the
  same message will be sent to many users, it might be better to
  instead keep message-id's in users, and store the actual
  messages some place else.

- When a user is not in @+channel-tokens+ he cannot be online, so
  there is no point in trying to send. 

- Expired tokens should be removed from @+channel-tokens+