test: introduce new StorageITRunner

[BenWhitehead]

A note to the reviewer:

This PR refactors the hole integration test suite and touches many files. However, the
majority of the files touched are not logically changing, simply changing how they declare
their test environment dependencies.

This PR is intentionally several commits, each commit is a small logical grouping of a
specific change. Take each commit in turn rather than the hole PR as a single change.

First read the rest of this description, then take a look at each individual commit.

The later majority of commits are simply migrating an individual test class to using
the new runners.

New StorageITRunner

Add two new JUnit runner to provide support for Cross Running test in a class across multiple
backends and transports.

When a class is annotated @CrossRun(transports = {HTTP, GRPC}, backends = {PROD, TEST_BENCH})
each test defined in the class will be ran four times, once for each pair from the permutation.
Each permutation will add a new entry to the test suite of the form [Transport][Backend].
This name form can be thought of as keys to access a location in an adjacency matrix.

If only a single backed is needed @SingleBackend() can be used to denote the backend.

If a class is annotated @ParallelFriendly the test suite may attempt to run the tests in
parallel. Currently parallelism factor is set to 2 * core count.

Field @Injection

When defining the test several "globally scoped" items are available for injection to the test
class by annotating a public non-final field with @Inject.

Instances of Storage, along with BucketInfo, TestBench, etc. are registered as injectable values.
If a field isn't able to be injected an InitializationError will be raised with details as to why.

CrossRun.Ignore & CrossRun.Exclude

Not all tests in a class will apply to all intersections, to allow filtering out tests for
these cases there are two new annotations which can be used. If a test is both Ignored and
Excluded, the Ignore will take precedence.

@Ignored functions similar to the standard @org.junit.Ignore where the test will be loaded
but not ran.

@Excluded tests will not be loaded into the suite at all, thereby not being reported at all.

@Parameterized running

When a class is annotated @Parameterized(ParameterProvider) in addition to and Cross Run
previously resolved, each parameter will result in another dimension added to the suite.
The name of the suite will be extended with another dimension below any cross name,
for example [HTTP][PROD][myParam].

Runner Registry

A new class Registry has been added which is responsible for managing "globally scoped"
instances of resources associated with running integration tests. All injectable instances
are registered with the Registry and will be lazily initialized, reused and cleaned up.

Instances like Storage clients, Backend Buckets, standard objects etc are all managed per
backend.

When a BucketInfo is loaded into the registry it's name is also made available to the
provider for Storage instances. If a test attempts to mutate the state of a bucket the
operation will be interrupted with a vetoing exception causing the test to fail.

Refactoring Done

1. TestBench is now a Registry Resource and shouldn't be used outside that context. Since
   testbench binds ports it is not a multi instance thing anyway.
2. Remove StorageFixture in favor of Registry Field Injection
3. Remove BucketFixture in favor of Registry Field Injection
4. All IT test now use either of the two new runners
5. Remove ParallelParameterized runner, instead annotate your class with @ParallelFriendly
6. Move bucket cleanup utility from BucketFixture to new class BucketCleaner

TODO

Items to still perform in later PRs

• Add to contributing guide
• Make TestBench no longer be a JUnit Rule - it should only be injected by our runner
• Flush out StorageInstance proxy to prevent mutation of global buckets
• Make each test hermetic to allow it running in parallel
• Cleanup some minor TODO's in the Registry
• Validate class annotations such that if @BeforeClass/@AfterClass/@ClassRule are used
  an InitializationError is raised stating the fact they are unsafe and will be ran
  multiple times (once for each sub-suite generated when cross running).
  • Provide acknowledge and processed annotation to allow a test to use the above
    annotations at their own discretion
• Figure out why when running a single test the suite hierarchy shows up weird in intellij
  • The correct suite runs, simply the rendering is odd

[frankyn]

Thanks for the discussion, PR LGTM, I added an item to add documentation to the contributing guide for using this infrastructure / linking to javadocs.