[SSF-17]: Backend endpoints user gated

[dburkhart07]

ℹ️ Issue

Closes #117

📝 Description

For this PR, we added in user-specific gated authentication to a few endpoints. The initial problem that required this user gate was that we need to restrict certain endpoints that incorporate the id parameter to specific users (for example, a pantry with the id of 3 should not really be able to do anything involving pantries with ids of 2).

To implement this, we are now marking all endpoints with a guard that allows us to pass in a lambda function. This lambda function uses services within the controller to define how we should go about getting the desired id to compare to the id of the currently signed in user (if they are not the same, access should be denied).

We implement a guard with a decorator, just as we did with the role-based authentication. For the decorator, we created 3 things:

• A resolver to store and run our lambda function to get the proper id we are looking for
• A service registry. This allows us to easily resolve our services so we do not need to worry about circular dependencies. The lambdas resolve only the services that they need, and we use a moduleRef from NestJs to get the appropriate service class so we can actually execute the lambda functions. We store them in a cache so we do not need to keep getting them each time,
• A configuration for ownership checks. This is the top level component that we pass in with our @CheckOwnership decorator. It contains the name of the id for us to use in the parameter, as well as the lambda function that will be resolved.

For the guard, we use each attribute from the decorator to run the following set of logic steps:

• Get the request sent, including the user
• All user admin get to automatically bypass, so check that (this is easy to disable, it is currently 1 line of code)
• Extract the entity id from the request parameters using the configuration's id parameter
• Get the services that we need to resolve the lambda function
• Use the entity and services to resolve the lambda function and get our proper id value
• Compare that id value to the user's id to determine if they should have access

✔️ Verification

For testing, I looked into 2 specific cases. One thing we want to make sure with this PR is that it can handle several services being used in verification (for example with orders, perhaps we are given an order id, and to verify it we need to get the corresponding pantry id, which allows us to get the corresponding pantry which allows us to get the pantry user id which we can check with the signed in user).

For this, I added lambda function guards to an endpoint in the pantries controller (the one called in the request-form page), and one in the orders controller (the one called when we open up the order modal on the admin donation board). I tested both of these pages with and without the corresponding user id being my signed in user. For both of these, I was able to verify that I was kicked out when I wasn't authorized, and allowed in otherwise.

Both these tests ultimately ended up using the pantry_user_id field, but just got to it in different ways.

🏕️ (Optional) Future Work / Notes

This PR is primarily for infrastructure, and we will later need to adjust all of the endpoints accordingly when we decide who we want to give this endpoint access to.