Manage object mailKeys automatically in Mail instead of storing them on objects

Summary:
Ref T13065. mailKeys are a private secret for each object. In some mail configurations, they help us ensure that inbound mail is authentic: when we send you mail, the "Reply-To" is "T123+456+abcdef".

• The T123 is the object you're actually replying to.
• The 456 is your user ID.
• The abcdef is a hash of your user account with the mailKey.

Knowing this hash effectively proves that Phabricator has sent you mail about the object before, i.e. that you legitimately control the account you're sending from. Without this, anyone could send mail to any object "From" someone else, and have comments post under their username.

To generate this hash, we need a stable secret per object. (We can't use properties like the PHID because the secret has to be legitimately secret.)

Today, we store these in mailKey properties on the actual objects, and manually generate them. This results in tons and tons and tons of copies of this same ~10 lines of code.

Instead, just store them in the Mail application and generate them on demand. This change also anticipates possibly adding flags like "must encrypt" and "original subject", which are other "durable metadata about mail transmission" properties we may have use cases for eventually.

Test Plan:

• See next change for additional testing and context.
• Sent mail about Herald rules (next change); saw mail keys generate cleanly.
• Destroyed a Herald rule with a mail key, saw the mail properties get nuked.
• Grepped for getMailKey() and converted all callsites I could which aren't the copy/pasted boilerplate present in 50 places.
• Used bin/mail receive-test --to T123 to test normal mail receipt of older-style objects and make sure that wasn't broken.

Reviewers: amckinley

Reviewed By: amckinley

Subscribers: PHID-OPKG-gm6ozazyms6q6i22gyam

Maniphest Tasks: T13065

Differential Revision: https://secure.phabricator.com/D19399