Inverted, email-backed teams and organizations

[jace]

The Organization and Team models currently require someone to explicitly create them and manage their memberships. This a tedious and non-intuitive process. Hasjob, however, has shown us that organization affiliations can be deduced automatically from the email domain.

Lastuser has a half-baked version of this idea from #108 where Team has an associated domain and anyone with a matching email address is automatically added to it (and by extension, to the Organization).

It may help to invert this model to be completely bottom up:

1. A new TeamEmail that represents a shared email address. Anyone who can prove ability to receive at this address becomes a member of the team. Verification codes sent here are time-bound (use within 24 hours) but not use count-bound (more than one user can verify access). TeamEmail complements UserEmail, which can now lose the team_id column and associated check constraint (introduced in UserEmail/Claim and UserPhone/Claim should have org_id and team_id #125). TeamEmail and UserEmail share email field namespace, so the same email can't be used in both places.
2. Membership is valid for a limited period (3 months?) and users must continue to prove ability to receive at that address. A link in any email sent to that address should automatically update the timestamp to whenever that email was sent (but not when it was clicked). Related: verified_at date for UserEmail and UserPhone #178.
3. Users are automatically booted out if they don't re-verify.
4. A hard bounce boots out all members of the TeamEmail, but does not delete the TeamEmail to preserve referential integrity. Related: Removing emails from accounts #135.
5. When a user adds an email address to their account, we explicitly ask if this is a shared address, and if so make a UserEmail or TeamEmail as appropriate. It's unclear how to switch an existing instance, however (separate ticket required).
6. A new Domain or OrganizationDomain model similar to Hasjob's Domain model that is automatically constructed from TeamEmail. This model shares username namespace with the existing Organization and User models, which need to be updated to recognise it. This model also tracks its name and domain in separate fields, unlike Hasjob's Domain model.
7. A Domain has no owners. Rather, anyone who belongs to one of its teams can edit the domain (set name and title fields but not domain). Optional: owning an email address present in the WHOIS record should also be valid, assuming we can query and cache that efficiently.
8. If the Domain has one or more special teams (recipients of abuse@ or postmaster@, maybe other special emails), it's considered a "claimed" domain and only these team members have owner access.
9. Ownership is now distinct from roles (see Introduce roles alongside permissions #118) and anyone who can edit the Domain can assign or remove admin and other roles, allowing anyone else with those roles to also have rights.

Finally, we need to consider how Team and TeamEmail, and Organization and Domain can co-exist and perhaps be the same objects.

[jace]

This scheme doesn't work at all for a mobile number-based UX. We'll need a manual Organization and Team definition process for that UX.

[jace]

For point 7, the python-whois library seems useful and up-to-date.

[jace]

TeamEmail can be a principal as described in #91. In fact, if UserEmail (as last modified in #125) switches ownership to the Principal model, then the TeamEmail model is unnecessary. It can simply be a flag or a foreign key on the Team model linking back to the UserEmail model, locking it to that email address and switching on team membership semantics.

[jace]

mxsniff now offers email probes, as discussed in #178.

[jace]

Deprecated by #232. This should be a client app concern.