Start to use factories to generate test data

[grahamalama]

We use static data as test data throughout our tests. Some observations I've made about this data and the tests that use them:

• it makes test setup not obvious. I ask myself, "when a given test starts, what data is already present in the database?"
• they promote the use of "magic numbers"
• they're used in complex fixtures
• The division between "minimal" and "maximal" contact seems arbitrary

In this PR, we would introduce the use of test factories with Factory Boy and pytest-factoryboy. I've done minimal setup in this PR to demonstrate a proof of concept. This involved adding a scoped_session for database tests as well as making two example factories and using them in two example tests.

If we like this pattern, we can use it going forward with the goal of making existing tests easier to understand and new tests easier to write.

[leplatrem]

I like this!

Since migrating the static data to this will require some efforts, what are the next steps? Merge this and live with the 2 ways, and migrate later?

[grahamalama]

Merge this and live with the 2 ways, and migrate later?

Potentially. I don't know if this is a viable solution, but we could make it a point in PR review to say, "Did you modify a test"? If so, replace any static fixture data with a factory."

[bsieber-mozilla]

Do we need to modify this for active/inactive contacts? (I think active contacts should have double_opt_in to True)

[grahamalama]

I believe we will have to override this default for different test cases -- either we keep this as is and override double_opt_in where applicable, or vice versa.

We could also create additional factories with different defaults for different test cases.