v11 auth rules 2.2 is unclear in combination with auth event selection algo

Nobody has claimed this yet.

## Link to problem area
- [Auth rules 2.2](https://spec.matrix.org/v1.12/rooms/v11/#authorization-rules:~:text=If%20there%20are%20entries%20whose%20type%20and%20state_key%20don%E2%80%99t%20match%20those%20specified%20by%20the%20auth%20events%20selection%20algorithm%20described%20in%20the%20server%20specification,%20reject.)
- [Auth event selection algorithm](https://spec.matrix.org/v1.12/server-server-api/#auth-events-selection)

## Issue

2.2 of the auth rules says:

> If there are entries whose type and state_key don’t match those specified by the auth events selection algorithm described in the server specification, reject.

At the same time, the selection algorithm uses wording like "current [event of type T], if any".

Combining the two, I reason in the following way. Suppose I receive an event E, such that:

1. For some event A, `E.prev_events = [A]`.
2. `state_at(A)` includes a PL event (or join rules, or sender/target membership events, etc).
3. `E.auth_events` *does NOT* include that PL event (or join rules, or sender/target membership events, etc).

First of all, what is the meaning of "current" in the selection algo? Let's suppose it means "in the state at event A".

Then suppose:

- An auth event cited by E is not actually "current" (not in the state at A). So I should reject E?
- An event that would satisfy the auth selection algo *is* in the state at A, but E does not cite it. So I should reject E?

Discussing with @erikjohnston, neither of these are actually the case. That the cited auth events should be "current" (in the state at A) is merely a suggestion and the expected behaviour of honest participants, but it is not actually enforced. And leaving out any of the auth event types is permissible (due to the `..., if any` of all the selection algo clauses), despite them existing in the state of A.

According to Erik, the actual purpose of rule 2.2 is to *reject extraneous garbage auth events* rather than to specify which auth events (or rather, of which (type, state key) tuples) *must* be cited.

## What should be done?

- Clarify the purpose of auth rule 2.2.
- Make it explicit that qualifying (event type, state key) entries are allowed to be omitted from an event E's `auth_events` despite existing in the state at the point of the DAG where we are trying to insert E.
- In the selection algo, the status of the following "should" should be clarified and replaced with appropriate RFC2119 wording.
- Clarify what "current" means in the selection algorithm.

Start with Auth rules 2.2 and the auth event selection algorithm linked in the issue. Compare how “current,” omitted qualifying events, and extraneous auth events are described, then review the relevant RFC2119 wording. Done means the specification clearly defines these terms and states the intended allowance for omitted events.

Written by the indexing model from the issue text.