Auth rules are unclear about which checks apply to auth events and which to room state

Nobody has claimed this yet.

Per https://spec.matrix.org/v1.3/server-server-api/#checks-performed-on-receipt-of-a-pdu, we check the auth rules three times for each event, based on different subsets of state:
* based on the event’s auth events
* based on the state before the event
* based on the current state of the room

However, some of the auth rules *always* apply to the auth events, and some are completely independent of any room state input. In particular, per https://spec.matrix.org/v1.3/rooms/v10/#authorization-rules:
* Rule 1 ("If type is `m.room.create`:") is completely independent of the room state.
* Rule 2 ("Reject if event has `auth_events` that:") and rule 3 ("If event does not have a `m.room.create` in its `auth_events`, reject.") always look at the auth events, never the room state.
* Rule 4 ("If the create event content has the field `m.federate` set to false...") is unclear, but since there should be only one create event in a room which is constant throughout the tests, we can consider it as always looking at the auth events.

The rest of the rules are intended to apply based on the room state based on the three different state sets mentioned above - but do not say as much.

This is somewhat confusing for the reader, but also makes a faithful implementation rather inefficient, because if we implement it literally we'll check the first four rules three times for exactly the same input.

I've recently (https://github.com/matrix-org/synapse/pull/13065) split the two sets of checks into two functions in Synapse, and rather wonder if we should do the same in the spec.

Start with the specification sections “Checks performed on receipt of a PDU” and the v10 “Authorization rules,” then compare the separate checks described in Synapse PR 13065. Update the specification to state which rules use auth events versus each room-state set, including the treatment of the create event, and make the intended check sequence unambiguous.

Written by the indexing model from the issue text.