Access request locks

[espadolini]

This adds a way to add a lock on a specific access request; when such a lock is in force, any identity that has used that access request is prevented from interacting with the system - the user can however switch to a less privileged certificate, or log out and log back in again and regain their own regular access.

While it would be sufficient to lock the user out if malicious behavior was suspected, this helps in the case where elevated privileges are requested and granted by mistake; the request can be blocked and the user can then continue working with their own static roles (or with the roles granted by other access requests).

The types.LockTarget type will gain a new AccessRequest field, following the nomenclature of AccessRequests/access_requests already in use in the session.start event.

As locks are currently only supported on the tool side by tctl, the only addition to the UX is a new flag to tctl lock

tctl lock --access-request=261e80c5-357b-4c43-9b67-40a6bc4c6e4d

that matches the field name in types.LockTarget (converted to kebab-case as the other CLI options are).

Such a lock serialized as yaml (as output by tctl get locks or tctl get lock/<lockname>) looks like

kind: lock
metadata:
  id: 1640275041241490000
  name: 7f6d2edc-68cb-4b98-b2d4-859c75284c8a
spec:
  target:
    access_request: 261e80c5-357b-4c43-9b67-40a6bc4c6e4d
version: v2

Fixes TEL-Q321-3.

Docs PR:

• Add access request locks to the docs #9866

[russjones]

@espadolini Can you update the PR description with details on CLI UX?

Can you also update documentation (you can do that in another ticket) https://goteleport.com/docs/access-controls/guides/locking/