[SM-380] Access checks for listing projects

[Hinton]

Type of change

- [ ] Bug fix
- [x] New feature development
- [ ] Tech debt (refactoring, code cleanup, dependency upgrades, etc)
- [ ] Build/deploy pipeline (DevOps)
- [ ] Other

Objective

Add access checks for projects.

Code changes

• file.ext: Description of what was changed and why

Before you submit

• Please check for formatting errors (dotnet format --verify-no-changes) (required)
• If making database changes - make sure you also update Entity Framework queries and/or migrations
• Please add unit tests where it makes sense to do so (encouraged but not required)
• If this change requires a documentation update - notify the documentation team
• If this change has particular deployment requirements - notify the DevOps team

[Thomas-Avery]

In the ProjectsController integration tests, the_currentContext wasn't detecting that the logged-in user was a part of the organization or the organization owner.

From looking through the code, it looks like this comes from the user's ClaimsPrincipal.

With how the integration test was set up, we:

• Setup and login with a new account
• Sign up with the new account for an organization and set the new account as the organization owner
• Add the first login tokens onto the client's default request headers. Note these tokens are from the initial sign up prior to the organization creation, which is the root of the problem.

    public async Task InitializeAsync()
    {
        var ownerEmail = $"integration-test{Guid.NewGuid()}@bitwarden.com";
        var tokens = await _factory.LoginWithNewAccount(ownerEmail);
        var (organization, _) = await OrganizationTestHelpers.SignUpAsync(_factory, ownerEmail: ownerEmail, billingEmail: ownerEmail);
        _client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", tokens.Token);
        _organization = organization;
    }

New flow for the fix:

• Setup and login with a new account
• Sign up with the new account for an organization and set the new account as the organization owner
• Generate fresh login tokens by logging into the account again
• Add the new tokens to the request headers which contains organization ClaimsPrincipal information.

 public async Task InitializeAsync()
    {
        var ownerEmail = $"integration-test{Guid.NewGuid()}@bitwarden.com";
        await _factory.LoginWithNewAccount(ownerEmail);
        var (organization, _) = await OrganizationTestHelpers.SignUpAsync(_factory, ownerEmail: ownerEmail, billingEmail: ownerEmail);
        var tokens = await _factory.LoginAsync(ownerEmail);
        _client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", tokens.Token);
        _organization = organization;
    }

Feel free to modify and use as needed. But for now, all the unit tests are passing.

[Hinton]

Reminder to myself: Service Accounts API Key have a access level as well, more specifically Scope. We need to figure out a way to set read/write access to it. I think for now we can just remove the write logic for service accounts causing them to fail.