Test creation of API keys for other principals

[padraic-shafer]

This PR adds a test to verify that an admin can create API keys using the route /principal/{uuid}/apikey and that non-admins cannot. This test also verifies that a user cannot bypass the scopes checks by passing an empty scopes list when creating an API key and/or when requesting an admin resource.

The test is fairly long (in lines of code, not in execution speed). I could probably break it into several individual tests that are backed by some common fixtures. Do you have advice on keeping this more concise or clear?

[danielballan]

To my taste, a long-ish test that "tells a story" is more readable than lots of small tests that tell part of a story. This one is borderline too long, I agree, but I don't see a clean place to break it out or any obvious resusable abstraction that would be a natural fixture.

I do wonder if we should take this moment to promote create_api_key_other_principal to a method on Context. (I mentioned on Slack that I've found reasons to do this, and I usually end up doing it via the Swagger UI or via the http CLI, writing URLs by hand.)

I had in the back of my mind the idea of making an admin namespace hanging off of context, like c.context.admin.create_api_key_other_principal. First, this make the c.context.<TAB> namespace less cluttered with methods that will not be applicable to most users. Second, it communicates that not just any user can impersonate another user, which might otherwise prompt confusion or concern.

[padraic-shafer]

I had in the back of my mind the idea of making an admin namespace hanging off of context, like c.context.admin.create_api_key_other_principal. First, this make the c.context. namespace less cluttered with methods that will not be applicable to most users. Second, it communicates that not just any user can impersonate another user, which might otherwise prompt confusion or concern.

This sounds like a good idea to me.

[padraic-shafer]

To my taste, a long-ish test that "tells a story" is more readable than lots of small tests that tell part of a story. This one is borderline too long, I agree, but I don't see a clean place to break it out or any obvious resusable abstraction that would be a natural fixture.

Thanks for affirming this. I have two thoughts on how to simplify this, without too much effort. I'm out of time for now though. I'll move this PR to draft and attempt to resume it later this week.

[padraic-shafer]

I've split the new long test into several smaller tests, that I think are easier to digest. This PR is ready for review.

[danielballan]

This is good.

I left some suggestions for future-proofing and streamlining a bit.

[padraic-shafer]

Thanks for the reviews! I'll make these changes.

[padraic-shafer]

@danielballan All recommendations have been incorporated. This is ready for review.