GetCollectionItems use case, for returning dataset, collection and file item types

[GPortas]

What this PR does / why we need it:

Adds GetCollectionItems use case, for returning dataset, collection and file item types. Includes search text and type filtering option.

⚠️ Environment variables should be changed to unstable image tag before merging into develop. IQSS/dataverse#10811 should be merged before applying this change.

Which issue(s) this PR closes:

• Closes Create use case for getting file type search results in a collection #170
• Closes Extend GetCollectionItems to support search text filtering #183
• Closes Add use case support for collection result type filtering: Datasets, Collections and Files #184
• Closes Update getAllDatasetPreview use case to include 'Unpublished' publication status #171

Related Dataverse PRs:

• Search API results payload extension dataverse#10811

Special notes for your reviewer:

I have reduced branch test coverage from 95% to 90%.

The pre-commit hook was failing because branch coverage was not being reached in classes where there should be branch coverage, and it was showing 0%. I have created an issue to address this problem separately: #186

In a future iteration we will include collection type results.

Suggestions on how to test this:

Visual inspection of the code and github actions.

[GPortas]

Waiting for IQSS/dataverse#10810

[GPortas]

Waiting for IQSS/dataverse#10810 to be approved.

[GPortas]

parentAlias and parentName

parentAlias and parentName for the DatasetPreview

Thanks @ekraffmiller. We need to extend the API to add those missing properties. Not a big issue, but something to work on before updating this PR: IQSS/dataverse#10846

Adding the waiting tag.

[GPortas]

@ekraffmiller I have already implemented the remaining changes. I thought it was necessary to extend the API, but the properties were already being returned.

[g-saracca]

@GPortas sorry for not realizing this before, something crucial; we are going to need in each preview object (Collection, Dataset and File), the type of collection item it belongs to, so we can easily know in the SPA what type of preview object we are reading and display the correct card component.
A type property would be enough, which can be 'collection' | 'dataset' | 'file', as we use for UpwardHierarchyNode in the SPA for breadcrumbs.

[GPortas]

@GPortas sorry for not realizing this before, something crucial; we are going to need in each preview object (Collection, Dataset and File), the type of collection item it belongs to, so we can easily know in the SPA what type of preview object we are reading and display the correct card component. A type property would be enough, which can be 'collection' | 'dataset' | 'file', as we use for UpwardHierarchyNode in the SPA for breadcrumbs.

No problem. I just added it!

[ekraffmiller]

Looks good! Just one comment about the integration test.

[ekraffmiller]

@GPortas I think a test of actualDatasetPreview parentName and parentAlias can be added here?
Edit: Also need a test of type for the Preview objects

[GPortas]

You're right! I just added those assertions.

[ekraffmiller]

looks good to me!