fix(TestCache): eliminate hanging Windows tests

[smoyer64]

As seen on PR #933 and others, it's common for the Windows test suite to fail when run via GitHub Actions. In that PR, @zinderic also noted that it's less prevalent but can also occur on Mac OSX.

I can't test on Mac OSX but on the ext4 file system, the TempDir is deleted but it's asynchronous and only occurs when there are no open file handles (when the go test ./... ends). On Windows, removing the temporary directory is (more?) synchronous and so Go waits for the OS to remove the TempDir while the OS is waiting for the open file handlers to be closed.

As seen in the changed file, the solution is to explicitly close both instances of the cache as soon as they're no longer needed. I don't quite understand why the other cache tests don't have this problem but my intuition says that the tests would run faster if those caches were also explicitly closed.

I'm considering refactoring these tests a bit so that there's a t.Helper() to create and clean-up the caches being tested - what do you think?

[zinderic]

I've tested this branch on MacOS by running many times the TestCache test and I get no failures now. It seems that this fix makes the test stable on MacOS too.

[smoyer64]

Closing all test caches when we're done with them doesn't (as expected) change the speed of the tests on Linux. It's definitely interesting that the Windows tests take so much longer to run in GitHub Actions so it might be worth the refactor I mentioned above anyway.

[MichaelMure]

Good catch! Let's take the win and fix the CI for now. An automated cleanup could make sense but I'm not sure how that would combine with that specific test where we check a bunch of things after closing.

[smoyer64]

@zinderic I think if you rebase #933 from master now, the Windows tests will complete successfully and the GoKart security checks will be removed (at least temporarily) from the linting step.

[smoyer64]

@MichaelMure I'll put a separate PR in for the t.Helper() ... the answer to your question is that we'll wrap everything in one or more closures to make sure the execution order and test results are as expected. Will be done after work today :)

As an aside, did you have ideas for testing the bug and identities caches (and covering some of the other critical paths in the cache package code) or should I take a look?