Fix Testcase Class Setup/Teardown w/ MPI

[naylor-b]

Note that a similar bug exists with setUpModule/tearDownModule when used with MPI.

Reported by @sebasgo to naylor-b/testflo:

testflo sets _tcase_fixture_first and _tcase_fixture_last to its intended state during the test case discovery. This way, testflo ensures setUpClass() and tearDownClass() is only called for first or last test in a test class, respectively.

With MPI enabled, each test is run in its own process which instantiates new test instances where these attributes are kept at their default value (False). So setUpClass and tearDownClass are never executed.

[sebasgo]

With MPI enabled, I think there is no 100% correct solution for this problem. As @naylor-b mentioned at my original PR, the expected behavior in terms of the unittest library is that setUpClass() is called before the first test and tearDownClass() is called after last test of any given test class. (At least as long tests are executed in their default order. If random order execution is enabled, setUpClass() and tearDownClass() are executed multiple times)

To decide what what should be the behavior of these methods with MPI, I think one should consider what the intended usecase of the methods could be. unittests's documentation is very light on this topic, but starting from the method names, I think the main purpose of the method setUpClass() is to make changes to the test class (e.g. generate new test methods on the fly) before it is instantiated by unittest and tearDownClass() its counterpart for cleanup.

As testflo executes every single test in its own process in an fresh Python interpreter if MPI is enabled, such changes to the test class would not carry other from the first test to the remaining. Tear down also would happen only the last time before the test class is deleted by Python runtime. Here, executing these methods before and after each test would be advantageous.

Users could of course also do stuff with permanent side effects in setUpClass() / tearDownClass(), e.g. file IO or network requests. For these, the original behavior of unittest would be better.