Test cleanup/improvements:

[porcellus]

• Move startSTWithMultitenancyAndAccountLinking into a centralized helper (thread)
• Remove the info object from the overrideParams because it only wraps a single prop (thread)
• Make the linkingIfVerifyExceptWhenEmailMatchTest use an email address that includes DO_NOT_LINK instead of the generic [email protected]
• Reduce the number of custom overrides
  • We add a "default override" for shouldDoAutomaticAccountLinking that doesn't link if the userContext or the email address contains DO_NOT_LINK in all tests
  • We may also need to add an override for apis that allows us to add things into the userContext and slightly change tests to make use of it.
• Add an override that will make the tests not send emails/text messages. It should be disabled explicitly in tests that require it.
• Move from using overrideParams to using a more generic solution
  • Add a generic override function to all overrideable functions when initializing a recipe, which will:
    • Save a log about it being called into a centralised "override call log", with type: "CALL"
    • Call the original function, save a log item into the above log, with type: "RESOLVE"
    • If it catches an error it should save a log item into the above log with type: "REJECT" and rethrow
  • Add an endpoint that returns the above log, recursively serializing objects based on what functions are present on it (e.g.: if toJSON is present we call it)
  • Add functions extracting all information we used to get from overrideParams into the test utils and update tests to use those.
• Check if we can move to an override system where we can avoid using eval and manually implementing overrides in other languages:
  • It doesn't have to replace the current override system since we might need it for "special" overrides
  • It can be implemented/added into the above "default override"
  • As an example flow for fully custom overrides (this needs more thinking, take it with a grain of salt):
    1. Test initializes ST and starts calls.
    2. Simultaneously, it makes a call that waits for the override call. This call will wait until the aproriate override is called, then it responds with the parameters the override receives.
    3. The generic/default override sees that it needs input from the test runner, notifies the test runner by resolving the above request
    4. The test runner then sends a request instructing the override what to do next:
    • It could call the original impl with modified input
    • It could return a constant object
    • It could call the original impl then modify the return value
    • Combinations of the above
    5. The test continues