Revert "authz: silo endpoints (#936)"

[davepacheco]

This reverts commit 1019643.

#936 did pass all checks, but that was before sync'ing up with #937 (which also passed all tests). Together, there's a logical conflict that wasn't caught by git/GitHub. I'm reverting #936 until I can figure out the right fix for this.

[davepacheco]

I believe the problem is that:

• use the correct Silo for resource lookups #937 added an omicron.polar policy rule saying that users can "read" their own Silo. I think the reason was that organization_create() attempts to create an Organization in your Silo. If you can't read your own Silo, the authz subsystem turns this into a 404. It's like trying to create a Project inside an Organization that you don't have access to -- you have to get a 404 saying the Organization doesn't exist. If we allow you to "read" your own Silo, then this becomes a 403 instead (which is what we want).
• authz: silo endpoints #936 added an "unauthorized.rs" check for the default Silo and assumes that unprivileged users can't read it.

I can see a couple of options for fixing this:

1. Say that users can read their own Silo. The only (immediate) problem is that the "unauthorized" test needs to create some other Silo for unprivileged users to check. I think this should be possible so I'm going to explore that.
2. Say that users cannot read their own Silo. Fix the 404 above by instead checking for CreateChild on the Fleet. I don't like this because it puts policy into the code doing the authz check. That code should be able to say what it's really doing, not some inferred thing, and leave the policy to the Polar document and role assignments.
3. Say that users cannot read their own Silo, but fix the 404 above by using a custom implementation of the AuthorizedResource trait that returns a 403 rather than a 404. This essentially says that one's own Silo is visible even though you can't read it. That's a little weird because it's unlike all other resources, but it's not the worst. I'm also not sure how to do it because the current impl of AuthorizedResource is a blanket impl shared with a lot of other types.

[davepacheco]

As happens with disturbing frequency, GitHub has simply not kicked off some of the required builds for this change:

I expect the real fix, #947, will wind up landing sooner.

[david-crespo]

It's the job deduper. Drives me nuts constantly. What if we just turn that off?

[davepacheco]

It's the job deduper. Drives me nuts constantly. What if we just turn that off?

Ugh! How can you tell? Are you able to confirm it? I thought usually when it marks something "skipped" then GitHub knows not to expect the check.

[david-crespo]

https://github.com/oxidecomputer/omicron/runs/6082409170?check_suite_focus=true

[davepacheco]

Closing -- the real fix was done sooner (#947).