Fix the issue that was preventing us from upgrading pytest. pytest does some manipulation of test packages that prevents `pkg_resources` from loading resources from them, but used to contain a workaround for the problem. That workaround was [removed](https://github.com/pytest-dev/pytest/issues/5392) in 4.6.0 as a performance enhancement when pytest switched from `pkg_resources` to `importlib-metadata` for its own entrypoint handling. This tripped up one of our test modules which defined classes that loaded templates from inside a test package. Moving these resources to the parent package fixes the problem.
More and more, `pkg_resources` is being abandoned in favor of `importlib-metadata` and `importlib_resources` as they have a simpler design with much better performance. However, `importlib_resources` doesn't support loading files from any directory which isn't itself a Python package (and doesn't allow direct use of paths including directories within the package). Jinja2 chose a [different approach](https://github.com/pallets/jinja/pull/1082) that we may want to emulate in our resource handling.
Also fixed usage of a removed `pytest.raises()` parameter and a bug in our configuration of the `common/lib` tests that became a problem after the upgrade.
I'm surprised this didn't cause an issue before but as far as I can
figure this should always be non-greedy. I think it worked before
because the items we were looking for was previously the last item
in the list but that is no longer the case in python 3 because of
dictionary order changes.
These tests essentially duplicate the logic for how the pytest commands
are generated and then compare the duplicated logic to the original
logic. This is pretty brittle and since we're running all the variants
here pretty regularly I think we have other ways of knowing if we caused
the command to break.
I don't think these tests are providing sufficient value to merit their
added complexity.
They are running into issues because of a bug in moto but looking closer
at what they are testing. Both tests test the happy path of the
underlying function. In the happy path scenario all boto calls succeed
and all theses test do is test that but with all the boto calls mocked
out. So we're just testing whether the mock is a good mock of boto
which is not useful.
ran python-modernize and isort on files mentioned in INCR-390
ran python-modernize and isort on files mentioned in INCR-390
ran python-modernize and isort on files mentioned in INCR-390
ran python-modernize and isort on files mentioned in INCR-390
ran python-modernize and isort on files mentioned in INCR-390
ran python-modernize and isort on files mentioned in INCR-390
ran python-modernize and isort on files mentioned in INCR-390
