feat(NODE-2939): add new hostname canonicalization opts

[durran]

Description

NODE-2939
Also syncs NODE-2443 and NODE-2563

Updates CANONICALIZE_HOST_NAME options to accept true, false, "none", "forward", "forwardAndReverse".

What is changing?

When canonicalizing the host name when using GSSAPI, the driver will now behave as follows for these values:

• true or "forwardAndReverse": Performs a forward DNS lookup of the host and a reverse lookup of the IP address to obtain the hostname. If the reverse lookup fails the driver falls back to a cname lookup.
• "forward": Performs a cname lookup of the host.
• false or "none": Does no hostname canonicalization.

When syncing the spec tests some other auth spec tests we hadn't synced yet were there, so I decided to leave them and skip the single failure.

Is there new documentation needed for these changes?

None

What is the motivation for this change?

DRIVERS-1803 / NODE-2939

Double check the following

• Ran npm run check:lint script
• Self-review completed using the steps outlined here
• PR title follows the correct format: <type>(NODE-xxxx)<!>: <description>
• Changes are covered by tests
• New TODOs have a related JIRA ticket

[dariakp]

I'm leaving some comments here because we pulled in more specs than just this ticket, so we should tag the corresponding tickets on this PR and then close them when this merges

[dariakp]

Let's make sure we rebase after #3138 goes in, because the credential option parsing will be affected

[dariakp]

@durran Thanks for updating the tests! Would it be worthwhile/possible to add the expectations on the fallback behavior at each point in each case? Just to make sure we don't accidentally break that in the future? Edit: if possible, we'd also want to confirm that the final response correctly uses the reply of the respective functions (like, we'd want to stub the reply from the reverse lookup to return something different than the forward, and then make sure we use the reverse response)

[durran]

@durran Thanks for updating the tests! Would it be worthwhile/possible to add the expectations on the fallback behavior at each point in each case? Just to make sure we don't accidentally break that in the future? Edit: if possible, we'd also want to confirm that the final response correctly uses the reply of the respective functions (like, we'd want to stub the reply from the reverse lookup to return something different than the forward, and then make sure we use the reverse response)

We actually didn't want to stub the later case, which is why I opened https://jira.mongodb.org/browse/BUILD-14646 to get an integration test for it afterwards. But I can write a test that stubs out all the return values in the meantime.

[nbbeeken]

Thanks! LGTM

[dariakp]

LGTM - great job with the new tests!