Fixed irreversible data loss bug when preparing the app path repo
for tests
OLD BEHAVIOR
Remove untracked files from the working tree before and after
every test suite. The intention was to remove files that could
have been created by the tests, but this also removes all other
untracked files, including third-party plugins and themes.
NEW BEHAVIOR
There is now a triple locking mechanism protecting the state of
the app repository before tests are run so that after tests have
run, all file contents are restored to how they were before the
tests have run.
There are three locks, each guarding a different part of the
original repo:
* file
* commit
* stash
When the file lock is present, E107Base knows that any other file,
tracked, untracked, or ignored, was created by the tested code.
The file lock is checked into the commit lock, which saves all
tracked and untracked files in the form of a commit. This way,
uncommitted code can be tested without manually making a commit that
includes the untracked files.
The stash lock saves all ignored files in a Git stash. Ignored files
go in a stash instead of in the commit lock because they can be a
confounding variable affecting the outcome of tests. They are usually
user-configurable only and may not represent tested states.
When the saving is complete, E107Base will have access to tracked and
untracked files but not ignored files. The tests are run in this
configuration.
After each test suite runs, the repo is reset and cleaned to return
the files to the same state they were in before the test suite began.
Then, the locks are undone first by rolling back the commit lock,
which restores the originally uncommitted tracked and untracked
files. Next, the stash lock is popped, restoring the originally
ignored files. Finally, the file lock is removed, signifying that the
repo is back to its original data before the test suite was run.
In case of an ungraceful exit, at least one of the locks would be
left in the repo. The next time E107Base runs, locks are checked, and
if one or more are present, the repo is restored before the locks are
reestablished.
If the `git` command is inoperative, only the file lock is operative
and does nothing more than signify a test that is in progress or has
exited unexpectedly. Data protection is silently unenforced. This can
lead to unexpected tracked, untracked, and ignored file modifications
that will not be rolled back after a test suite has run.
