Integration Test DSL

[rajp152k]

Currently, goose devs need to write similar integration tests per broker implementation (see #202)

This PR targets this problem of having to repeat yourself by abstracting out the boilerplate and providing a minimal integration test DSL to test goose, without having to deal with the leaks of what broker implementation is being used underneath.

Coverage across brokers might vary and all implementations may not qualify for certain tests. Capability computations (static reflection (unimplemented methods would be abstract)) based on methods implemented (of the broker protocol) help kick off a generic test loop that only tests a particular broker when it satisfies the requirements for that scenario.

testing a new broker implementation only involves registering fixtures, (client and worker) opts and the static implementation as data (in a broker utilities map and a vector that capability computer picks up), that the engine later picks up and executes upon.

The final def-integration-test anaphoric macro enables concisely communicating domain specific intent by only demanding what is needed (test scenario, requirements, distilled body), while exposing templatized anaphoras (broker and test-name).

the plumbing of checking side effects of an execution, picking up broker utilities are neatly abstracted away as well.

[rajp152k]

experimental def-integration-test macro for abstracting out further boilerplate logged here :
be81d1d

proceeding with more minimal and decisive refactors towards closing this PR for now:

• get rid of alter-meta!s : testing blocks handle reporting - further allows parallelization
• retain clojure.test semantics for fixtures and instead alter the test utilities to have finally clauses for cleanup
• atoms of promises instead direct resets to eliminate the flakiness of thread/sleeps
• further misc syntactic choices (thread out nested calls in some places, etc)