types: correct handling of _id in ProjectionType

[vkarpov15]

Summary

Quick fix for #15418: looks like we need to explicitly Omit<T, '_id'> to avoid TypeScript getting tripped up by _id in InclusionProjection and ExclusionProjection.

Examples

[Copilot]

Pull Request Overview

This PR addresses issue #15418 by correcting the handling of _id in ProjectionType and ensuring that both inclusion and exclusion scenarios for _id are properly tested.

• Adds tests to verify explicit inclusion/exclusion of _id in projections.
• Ensures that common projection usage with _id behaves as expected in TypeScript.

[vkarpov15]

This will fix #15431

[DavideViolante]

Just a question about the tests, what's the difference between line 164, 167 and the newest 190-191? Seems like all of them check with _id: 0 and another prop: 1. Why line 164 or 167 passed the test before this PR?

[hasezoey]

LGTM

Just a question about the tests, what's the difference between line 164, 167 and the newest 190-191? Seems like all of them check with _id: 0 and another prop: 1. Why line 164 or 167 passed the test before this PR?

At least line 191 is new as there previously was no _id: 1 test.

After some slight looking around and guess-work, it might be related to Model.find making use of ProjectionType<TRawDocType> where in the tests TRawDocType (interface ITest) does not include a _id property, but the example interface IUser in #15431 does. So my best guess is that in the tests it worked due to the & AnyObject clause in ProjectionType.

[vkarpov15]

My best guess would be because existing tests have multiple fields with : 1, whereas the new test only has 1 field with : 1. TypeScript is full of surprising quirks and behaviors.