Fix the UI to correctly determine if a user has access to a resource

[codingllama]

Introduce the GuessIfAccessIsPossible method, so callers may verify if a user has access to a category of resources, instead of access to a specific resource.

Fixes a bug where the "Session Recordings" menu doesn't show for users with where-based roles.

[codingllama]

Issue #5430.

FYI @russjones, this fixes the bug we talked about yesterday.

[codingllama]

Friendly ping @jimbishopp @timothyb89? We want to get this out for 8.1, so I wanted to merge before I'm out for recess, if possible.

[fspmarshall]

I see what this is going for, but it definitely feels a bit brittle and easy to misuse...

IIUC the problem we are trying to solve here is that not all variables are in-scope at this level to evaluate the where clause correctly, yeah? I'm wondering if it would be possible to handle that specific case, rather than evaluate all of these expressions to true/false. I.e. is it possible to distinguish between a where clause that actually doesn't match, and a where clause for which a match is not decidable? I haven't looked at the internals of the where parser in a long time, so maybe that isn't a reasonable ask. Definitely worth looking into it though.

If it is possible to differentiate between where clauses that can't be evaluated versus those that fail, then I'd prefer that we implement a function which returns an enum (e.g. Allowed | Indeterminate | Denied). Something which clearly communicates this in-between state where we aren't sure if the where clause passes.

Regardless of whether or not the above is possible/practical, lets rename this method to something that really screams "not a valid RBAC check" (e.g. GuessIfAccessIsPossible). We don't want someone ever looking at this method and thinking they can make a real access-control decision based on its results.

[codingllama]

Thanks for the feedback, @fspmarshall.

Let's start with the easy part: I like the rename and it seems a good way forward, so I'll go ahead and apply that.

I'm not looking forward to adding a 3rd possible response to CheckAccessToRule, the knock-on effect in Teleport seems worse than the new method, plus our Parser and Predicate concepts aren't really built for 3-state responses.

WDYT? Could we move forward with the new naming? (tagging @russjones)

[codingllama]

Friendly ping to reviewers?

[timothyb89]

I don't mind this, especially with the name change.

[codingllama]

Thanks everyone.