(TenantNetworks) CRUD and endpoints for tenant networks
Rename top-level test for tenant networks
(TenantNetworks) Fix trailing whitespace
(TenantNetworks) Delete unused DAO method
(TenantNetworks) Don't 'return' a non-final execution
(TenantNetworks) Review followup, fix unit test failure
(TenantNetworks) Missed one last test header comment
Fix compatibility with passport 0.2.0
Merge pull request #756 from mrvisser/passport-broken-build

Fix compatibility with passport 0.2.0
Google authentication: limit to a domain

Adds a config value which allows a tenant admin to specify the domain
to which the authentication should be limited.

If this value is specified, the user will not be presented with the
account choser and be taking straight to the login view for that domain.
Purist change: Changed 'ex:' to 'e.g.,'
Removed trailing comma
(Release 4.1.0) Bump version
(Release 4.1.0) Remove shrinkwrap
Ensuring that the same mail doesn't get sent to the same user twice

Disclaimer: This is a stop-gap measure until email aggregation lands.

The email API will now try to get a lock (in Redis) each time it tries to send an e-mail.
It will lock on either:
 * a new optional field called `id`
 * if left unspecified it will lock on: mail headers (to + subject + txt body + html body)

This has a couple of effects:

1. Mass-emails on broken activity router
Although it's unlikely that the activity router gets stuck again, the mass flood of emails
is too annoying/upsetting to even have it as a remote possibility.
If it evers gets stuck in a loop on a particular seed again, it will no longer send out multiple emails for the entities involved in that activity

2. For activities the mail id = `to + activity.type + activity.published`
For activities that are generated in very quick succession, some emails might never get sent.
Imagine the following situation:
Alice uploads 50 content items and shares them (in the create request) with bob
If the files are small enough that 2 `content-create` activities get generated in the same millisecond there will be an identical mail ID for 2 activities.
This seems very unlikely, but it is a possibility
#759 PR followup

 * Renamed opts.id to opts.hash in the sendEmail API
 * Various code/jsdoc cleanup
Pull in fix for buffer overwrite in amqp module
Use git:// for package.json github reference
Merge pull request #761 from mrvisser/amqp-0.1.8.x

Pull in fix for buffer overwrite in amqp module
email hashing - PR followup - cleaned up jsdoc