Runtime: Apply access policies to alerts returned in ListResources

[begelundmuller]

Makes sure only admins and alert owners/recipients can fetch alert details.

Closes https://github.com/rilldata/rill-private-issues/issues/250

[nishantmonu51]

this seems odd, usually when no attributes are available, minimum permissions should be assumed.
Why do we need this ?

[begelundmuller]

The basic reason is that the JWT attributes are only empty if a) it's a service token, or b) it's on localhost. In both cases, admin-like behavior is required.

More high-level, it's an annoying mix of issues:

• We don't support security policies for alerts/reports, so need to hard-code the access logic for UI-managed alerts/reports directly in the runtime.
• The runtime JWT claims are not defined for service accounts (and in general, there's not a way to know what kind of claims it is – could be unauthenticated localhost, assumed user on localhost, cloud user, cloud service, or custom attributes).

Hence, the TODO in this PR:

// TODO: This implementation is very specific to properties currently set by the admin server. Consider refactoring to a more generic implementation.

[nishantmonu51]

but doesn't it mean a some can send a request without these JWT attributes and get an unfiltered list back ?

[begelundmuller]

The JWTs are signed using the admin service's private key, so it can't be forged.

(And the JWT is verified in the runtime server's middleware. And there are checks in the API resolvers that ensure the JWT has permission to get/list resources, so unauthenticated requests will bounce.)