fix(index.d.ts): types for aggregation pipeline stages

[jeremyben]

Summary

Using more and more aggregations in our projects, I decided to type accurately every pipeline stage according to the last mongodb documentation.

Now I'm proposing it for the mongoose package.

It does not narrow what cannot be narrowed (expressions for example, are still typed with any).
Only Pipeline stages are typed, pipeline operators types are not implemented, as this would require a lot of work.

Example

Following the first aggregation example in the MongoDB doc: https://docs.mongodb.com/manual/core/aggregation-pipeline/#complete-aggregation-pipeline-example

With a model Order that implements the following interface:

{ 
	_id: ObjectId, 
	productName: string, 
	status: 'new' | 'urgent',
	quantity: number
}

The following aggregate request is almost fully typed:

const urgentProductsByQuantity = await Order.aggregate<{ _id: string, sumQuantity: number }>([
	  { $match: { status: "urgent" } },
	  { $group: { _id: "$productName", sumQuantity: { $sum: "$quantity" } } } 
])

Comparing with the present aggregate signature any[], this is quiet an improvement IMHO.

[vkarpov15]

Overall, I like this PR, but my biggest concern is that this represents a non-trival increase in TS' memory usage and # of instantiations. With the benchmark from #10349,

Before this PR:

Instantiations:             216148
Memory used:               174112K

After this PR:

Instantiations:             221961
Memory used:               180364K

Not terrible, but it also unfortunately undoes some of the gains we made in #10349. And, with TypeScript, the issue unfortunately comes down to the fact that the TS compiler is often too slow to handle accurate types, particularly with complex objects.

I'm leaning towards merging this but I'll take some more time to review.

[vkarpov15]

This change is incorrect, because we need to support the aggregate(pipeline, cb) syntax. Please add back aggregate<R = any>(pipeline: any[], cb: Function): Aggregate<Array<R>>;

Thanks for fixing the issue with returning Promise though, that is an issue in our type definitions.

[jeremyben]

Will revert back the two params signature 👍 .

[jeremyben]

About performance, how about removing the generic T from PipelineStage<T>, as it only helps for autocompletion of only a few stages like $match ?
Or do you think that the problem is not about the generic but the whole single property object big union ?

[vkarpov15]

Gonna merge this into the 6.1 branch and make the suggested changes: removing the generic from PipelineStage and revert to the correct signature.