fix(NODE-5171): allow upsertedId to be null in UpdateResult

[baileympearson]

Description

What is changing?

UpdateResult is now generic over a collection schema type. UpdateResult.upsertedId has two changes: it can now be null, and the type is inferred from the collection schema.

Collection.update* methods now return an UpdateResult that is generic over the collection's schema.

Is there new documentation needed for these changes?

What is the motivation for this change?

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

[dariakp]

This doesn't account for setOnInsert or other ways of setting the _id on the new document

[baileympearson]

What are you saying the correct type should be? Either way, we have no way of knowing what the actual id type is. Should we type it as unknown?

[dariakp]

Both the filter for the operation and the $set and $setOnInsert operators match against TSchema, meaning that if an _id is passed it at all, it would be constrained to InferIdType, so it would make sense to do that here, too. It's true that this does not account for the _id being missing entirely resulting in the ObjectId being generated server-side, but this is a similar issue to what we have in, for example, insertOne and insertMany (if the user does not provide an _id or a pkFactory), with the only difference being that a pkFactory can't be applied here as a backup. So if we follow our existing pattern, we would call the use of the upsert without specifying an _id in the case of a custom _id TSchema "incorrect usage", and advise the users in our documentation because TypeScript can't effectively catch that. Our operating assumption is that users performing upserts do not want to introduce inconsistencies into their schema, if one exists. But we can discuss that further with the team if you believe there is a stronger argument to be made for unknown.