windows unit tests fail is upgrade steps it will never really do

[Curtis Hovey]

Master now consistently fails because of this issue
    http://reports.vapour.ws/releases/issue/559acfbe749a565572d289f1

We see cases in windows tests where the test or juju cannot access the test files because the handle is invalid or another proc has the file. Once this issue is seen, we expect to see similar failures on the machine.

The issue is old and has been seen intermittently over several months. Now it is not intermittent in master; The last pass was commit 72ead90. The suspect commits are
    https://github.com/juju/juju/commit/c932fcebc0c7e48b77f14804c7e2f740761ce6eb
    https://github.com/juju/juju/commit/6f212f44edd3240b06b9acd80c112e617cf72e64
    https://github.com/juju/juju/commit/5f42e7a1e2d9b020117738047db9cf71bf3576af
    https://github.com/juju/juju/commit/073b0e55d25bc393241223b0adc33fde1e05a54f
    https://github.com/juju/juju/commit/034a78d37d55b5fe0f9ea53fd3059f405f567609

A recent failure looks like
    http://reports.vapour.ws/releases/3376/job/run-unit-tests-win2012-amd64/attempt/1657

[Bogdan Teleaga (bteleaga)]

https://github.com/juju/juju/blob/resources/apiserver/charmresources/package_test.go#L45

s.BaseSuite.SetUpTest(c) is not called. Due to the way I wrote the suite in testing/base_windows it will fail everytime TearDown gets called without SetUp being called first. I'm expecting to see this error more often.

[Curtis Hovey (sinzui)]

We believe this issue is fixed, but CI did not bless the revision. We believe the failures were caused by a confluence of recent changes.
    1. xenial unit tests should not be voting at this time because Go 1.5 is finding a lot of intermittent errors
    2. The client-server test is not valid for 1.26/2.0 and should have exited early
    3. The machine that hosts the openstack deployment is very slow