Harbormaster failed remote builds in B21574: Diff 47722!

Oh, this is a MySQL charset/version thing:

Target Error
phabricator_unittest_l2h564al5pey5px3d6vtdznc_auth.auth_contactnumber.key_number #1071: Specified key was too long; max key length is 767 bytes

The easiest way to fix this it to change contactNumber from text255 to text128.

I think I'm going to deal with this by adding a contactNumberUniqueDigest sort of column with digestForIndex() and putting the unique constraint on that instead though. Some considerations:

• I expect this key to eventually be on <contactNumberType, contactNumber>, e.g. you can have 555-555-5555 as a phone number (<phone, 555...>) and someone else can have that as an ICQ number (<icq, 555...>). If we put it on the actual columns, we may have to keep smushing things or risk running out of bytes, since we can only have ~191 total characters in the key.
• I may want this key to only guarantee uniqueness of non-disabled contact numbers. An easy way to do this would be to make the key column nullable, and have the object return NULL for its unique key if it is disabled, and an index digest otherwise.
• This gives us more tools to normalize numbers for uniqueness: the value for the digest can be more normalized than the contactNumber value. For example, we can store +1 (555) 555-5555 but hash +15555555555 if we want, or let users store 1-800-CALL-SAUL but hash +18002255728.
• Some "contact numbers" -- notably postal addresses -- may be more than 255 characters long. I'm not really sold on implementing "postcard MFA" yet, but don't want to completely write it off since it might actually be kind of reasonable in some cases. Sending users postcards is also fun and cute and this software platform is mostly about being fun and cute, with technical and product considerations a distant second.
• This makes one line of uniqueness-testing code cleaner and more future-proof (the ->withContactNumbers(...) uniqueness test). As written, it would need to change for ICQ support. With a separate uniqueness column, it'll be good as-is.

Another case is that "phone" and "whatsapp" are different contact mechanisms but it looks like they should actually be in the same "uniqueness namespace", i.e. if you have <whatsapp, 555...> another user shouldn't have <phone, 555...> for the same number. We can hash "phone:555..." for both of them while still knowing that they're different record types.

I have some war stories about normalizing phone numbers... IIRC, the worst offender is Brazil (numbers may vary in length).

I have zero experience with phone numbers but I'm sure they're highly regular, unambiguous, and users have totally consistent expectations about how to input them and how they should be formatted.