Fixes segfault caused by accessing destroyed logging object when test fi...

The order of destruction of static objects after the tests finish is the reverse of the order of construction, so logging first then the environment. A logic error in the code, during the destruction of the environment, was checking whether the bootstrap file is successfully removed and if it is attempts to log the error.


The class is part of the test set up and the file gets created when the environment is created, as such the file should always exist when the object is destroyed. Whether the call will actually throw is platform/case dependent, for the case where the file doesn't exist the function return's false, and since no special permissions are added the likelihood of throwing is small on removal. By virtue of it not affecting production code it may not be too bad if it does throw, provided gtest gives a reasonable message for the exception. I'm not sure whether that is typical behaviour for such a situation, but the same file will be written/deleted on each run of the test suite and if it becomes inaccessible we probably want to know about it in both release and debug mode.