Fix running auth tests

[alcaeus]

While changing test setup to rely on drivers-evergreen-tools, I missed that the AUTH variable needs to be "auth" for drivers-evergreen-tools while "yes" was used for our own scripts. This PR updates the build config and fixes a test that can be flaky due to potential elections in the replica set.

[jmikola]

Is this still a potentially flaky test if the order of servers returned by getServers() is non-deterministic? If so, perhaps this needs to be rewritten to instead have a function that asserts any server has certain tags. For example:

function assertSomeServerHasTags($servers, $expectedTags) {
    foreach ($servers as $server) {
        if (array_intersect_assoc($expectedTags, $server->getTags()) === $expectedTags) {
            printf("Found server with tags: %s\n", json_encode($expectedTags));
            return;
        }
    }
    printf("No server has tags: %s\n", json_encode($expectedTags));
}

$servers = $manager->getServers();
assertSomeServerHasTags($servers, ['dc' => 'ny', 'ordinal' => 'one']);
assertSomeServerHasTags($servers, ['dc' => 'pa', 'ordinal' => 'two']);
assertSomeServerHasTags($servers, []);

My understanding of array_intersect_assoc() is that its return value uses the same key ordering as the first argument, which makes it possible to do the === check above.

[alcaeus]

Good point. I've kept the loop but removed the use of array_intersect_assoc, as the last check will match for any server:

php > var_dump(array_intersect_assoc([], ['dc' => 'pa', 'ordinal' => 'two']));
array(0) {
}

A loose equality check works around this, and since we're expecting the tags in the order that we create them I think that should be safe but still protect us against non-deterministic order of the server returned from getServers().

[jmikola]

Suggestion to change to strict equality in the test, but LGTM either way.

[jmikola]

If getTags() returns an array, is there any reason we can't do a strict equality check here?

Both are going to enforce the same order AFAIK, and the associative array itself just has string keys and values (no concern with mismatched types).

[alcaeus]

I changed to a strict comparison, which then caused tests to fail again. With some debug output, I was able to capture the following diff:

003+ No server has tags: {"ordinal":"two","dc":"pa"}
004+ Server tags: {"localhost:27017":{"ordinal":"one","dc":"ny"},"localhost:27018":{"dc":"pa","ordinal":"two"},"localhost:27019":[]}
003- Found server with tags: {"ordinal":"two","dc":"pa"}

As you can see, the tags returned for the second server has a different order from the first, which causes a strict equality check to fail. I've added a comment to clarify why we're using == in the test for future reference.