This addresses xds_end2end_test flakes caused by lingering shutdown from a previous test impacting the following test. As an example, one common flake pattern was the following:

1. A test that uses load reporting finishes, but the channel code is not yet done shutting down its LB policies.
2. The next test, which does not use load reporting, starts up. The first thing it does is clear the global XdsClient instance, so that the new test will create a new one that points to the new xDS server instance.
3. At this point, the lingering client code from the previous test winds up creating a new XdsClient instance, which means that the lingering client code from the previous test will now be talking to the xDS server instance for the new test.
4. The client code from the previous test starts a new LRS stream, since the previous test was configured to do load reporting. However, the new test is not configured for load reporting, so when it sees an LRS stream, the test fails.

To fix this, we make two changes.

First, we change the order in which we initialize the infrastructure for each test. We now set up the new xDS server instances before we clear the global XdsClient state, which gives the previous test more time to finish shutting down. Note that this is still not a complete guarantee that the previous test will be finished shutting down by the time we clear the global XdsClient state, so it may still be possible for there to be more flakes in the future. But in practice, it seems to give enough leeway to avoid the problem.

The second change is to stop reusing ports between tests. Reusing ports between tests means that the xDS server will usually be on the same port, which means that the lingering client code from the previous test will wind up talking to the xDS server instance from the new test. Not reusing ports avoids this by ensuring that any lingering client code from the previous test will not interfere with the state in the new test.

Note that the code to reuse ports between tests was added back in #20787 to address a limitation of the number of ports that can be used by a test internally. To avoid hitting that internal limit, I have increased the number of shards for the test, so that each test instantiation is using fewer ports and therefore not bumping into the limit (which I have verified). I have also added a TODO for ways that we can further decrease port usage in the future.

With this PR, there is no more risk of cross-test contamination with regard to communication with the backend or balancer instances themselves. The only remaining risk here is that it's still possible that the previous test might still recreate the XdsClient after the new test clears the global state, but the probability of that has been lowered by changing the initialization order of the tests.