Refactor repairify

[ericworkman]

@mbramson I wanted to get this down for you to at least look at and to track remaining work. I tried using structs to somewhat structure the data that the builder and pairer return. This more or less works, but it has some odd edge cases and missing features.

• [x] Ignore pairs that have retro'd when finding available pairs for single users
• [x] Decide the boundaries and responsibilities of these new things
• [x] Flesh out some of the more complicated test cases, especially for the Pairer
• [x] Settle on the proper structs for PairBuilder and Pairer Happy enough with these.
• [x] Account for the case where the sole existing pair already has 3 members

[ericworkman]

@mbramson Leaving off the pipeline stuff we discussed. I'm calling this complete for now. I may go back and refactor and rename some things in the future. As long as neither of us has better names, these are staying.

I made a couple decision in regard to pair length. I decided to never increase a 3-pair, not to break up 3-pairs just to pair with a new user, and that 1-pairs are okay if there are no other options. If the 1-pair (with an existing 3-pair) isn't okay, an admin can go in and inactive a user in the 3-pair, repairify, reactivate the user, and then repairify.

I encourage to to try out as many weird test cases as you can.

[ericworkman]

@mbramson Excellent call outs 👍 I've refactored the builder in line with your comments and a refreshed look.