refactor(NODE-6174): use client.s.options in session

[durran]

Description

What is changing?

When constructing a ClientSession don't use the spread options, instead uses the options directly.

Is there new documentation needed for these changes?

None

What is the motivation for this change?

NODE-6174

Release Highlight

Fill in title or leave empty for no highlight

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
  • Example: feat(NODE-1234)!: rewriting everything in coffeescript
• Changes are covered by tests
• New TODOs have a related JIRA ticket

[nbbeeken]

This is fine for addressing the potential slow down but how would we feel about removing the footgun?

I'm thinking that the Readonly<MongoOptions> return type on the client.options getter is probably "safe enough" such that we could just return client[kOptions] directly. cc @baileympearson

[baileympearson]

I think freezing is nice because it's a runtime guarantee. But why not just freeze the options once at the end of the constructor and make options a property instead of a getter?

[nbbeeken]

That would break the places where we write to the options object, monitorCommands can change at any time, and we stick the TLS values read from files back onto that object. I'm fine with it as is too, just suggesting.

[durran]

It is worth noting we do have a unit test that verifies we freeze all public options, so returning kOptions and not freezing it does fail that test. Seems like we just want to stick with the original client.s.options potentially then?

[nbbeeken]

LGTM this should clearly have some improvement, so I'll merge this when CI completes. Did we regain the ~9% reported by devtools?