feat: add include filter support to the GET /api/v3/proposals endpoint

[jekabs-karklins]

Description

Add include filter support to the GET /api/v3/proposals endpoint, allowing callers to request associated samples inline within a single query.

Motivation

The proposals endpoint only supported simple find() queries with no relation expansion. We used to need to make separate requests to fetch samples belonging to a proposal. The dataset endpoint already supports this pattern via MongoDB aggregation $lookup stages - this change brings proposals to parity.

The following query now works

curl -X 'GET' \
  '<backend>/api/v3/proposals' \
  -H 'Authorization: Bearer <token>' \
  -H 'accept: application/json' \
  --data-urlencode 'filter={"where":{"proposalId":"123456"},"include":[{"relation":"samples"}]}'

Fixes

SWAP-5421

Changes:

• Added src/proposals/types/proposal-lookup.ts — defines ProposalLookupKeysEnum and PROPOSAL_LOOKUP_FIELDS with a $lookup stage joining Sample on Sample.proposalId = Proposal.proposalId
• Added src/proposals/interfaces/proposal-relations.interface.ts — IProposalFilters, IProposalRelation, IProposalScopes types mirroring the dataset filter interface pattern
• Added findAllComplete(), addLookupFields(), and extractRelationsAndScopes() to ProposalsService — builds an aggregation pipeline with optional $lookup stages and applies scope-level where, fields, limits
• Updated GET /proposals in ProposalsController — routes to findAllComplete() when include is present in the filter, otherwise falls back to existing findAll()
• Updated IncludeValidationPipe — extended the strict union type to include ProposalLookupKeysEnum alongside the existing dataset and origdatablock enum types

Tests included

• Included for each change/fix?
• Passing?

[nitrosx]

Currently proposal have only API v3 implementation.
In your code you are somehow mixing api v3 and v4 for proposal filters and relations.
I'm not sure i understand if it is needed.

In general we try to keep implementation for api v3 and v4 separate, so it will be easy to remove older implementation that are marked as obsolete.

[nitrosx]

Can you clarify why you are mixing proposal filter v3 and v4?

[jekabs-karklins]

I was keeping it similar how it was done with the datasets.

src/datasets/interfaces/dataset-filters.interface.ts
Also there we have

export type IDatasetFilters<T, Y = null> =
  | IDatasetFiltersV3<T, Y>
  | IDatasetFiltersV4<T, Y>;

[jekabs-karklins]

I have kept now only the v3, becayse you correctly pointed out v4 is not there yet.. However I see no issues of moving relation expansion to the v4 once we have the base of /api/v4/proposals implemented.

[nitrosx]

Same as above, can you clarify why you are mixing api v3 and v4?

[jekabs-karklins]

And same here

[Junjiequan]

I second to Max's comment, lookup should be v4 feature instead of exiting endpoint

[jekabs-karklins]

I second to Max's comment, lookup should be v4 feature instead of exiting endpoint

Sorry, not sure I follow, Do you suggest not to use V3 at all?

[Junjiequan]

Sorry, not sure I follow, Do you suggest not to use V3 at all?

Yes, we try to keep v3 endpoints as it is now with old implementation and deprecate them as soon as we are ready.
The lookup with aggregate pipeline is the new implementation for the v4 endpoints.

[Junjiequan]

LFTM.
Ideally the include implmentation should be in the v4 endpoints exclusively, but for a temporary solution this works.