Feat: add endpoint to check user access for sample and proposal

[Junjiequan]

Description

This pull request introduces new endpoints to check user access for specific samples and proposals. It includes updates to the authorization mechanisms and related test cases to ensure proper access control based on user roles and permissions.

Additional:

1. Added configurable test database environment variable is added for local testing.
2. Replaced deprecated casl-factory AbilityBuilder with updated one.

Motivation

When a user opens a dataset detail page, the frontend makes requests to fetch the Sample and Proposal attached to the dataset, regardless of whether the user has permission to access them. By utilizing user access endpoints, we can pre-check if the user has access to the Sample or Proposal before making subsequent requests. This can reduce the collection of FALSY errors.

Changes

New Endpoints:

• Added /samples/:id/authorization and /proposals/:pid/authorization endpoints to check if the user has access to specific samples and proposals.

Authorization Updates:

• Modified CASL ability factory to include updated types and conditions for checking access permissions.
• Updated policies guards to handle access control for the new endpoints.

Tests:

• Added test cases for new endpoints in ProposalAuthorization.js and SampleAuthorization.js to validate access control for different user roles.

Tests included

• Included for each change/fix?
• Passing? (Merge will not be approved unless this is checked)

Documentation

• swagger documentation updated [required]
• official documentation updated [nice-to-have]

official documentation info

If you have updated the official documentation, please provide PR # and URL of the pages where the updates are included

[Junjiequan]

The decision on whether to allow users to update the isPublished status of proposals requires further investigation. In the proposalAuthorization test file, test cases for public proposals are temporarily commented out.

[nitrosx]

Please check my comments and let me know if we need to discuss

[nitrosx]

I'm not sure what is the correct solution, but I think that have a separate variable to set the dataset in testing will lead to confusion.
I think we should rely only on the value MONGODB_URI. If you are testing locally, you will change the value of MONGODB_URI according in order to use your local database.

[Junjiequan]

I think we should try to avoid relying on MONGODB_URI for testing.
If you by accident, run the test locally without changing the MONGODB_URI the test will wipe off all the local DB data

[nitrosx]

I see your point, but by using the two environmental variables, we are forcing developers to change the database name in two places instead of one.
Also I feel that we are not minimizing the risk to wipe a local DB data. It is still very much present.

[Junjiequan]

I'd suggest to just hardcode test db as scicat-test-db in this file like the appUrl

[nitrosx]

Waiting for the changes on pretest