Remove deprecated CSRF check with 'rest' key

Seems there were a number of failures.

The login controller was still using the old token. I need help determining if this basically re-starts the clock on actually removing this b/c in theory you could break a login that is happening _during_ a site update? That doesn't particularly seem like a strong case to me because lots of changes can mean a really well-timed request might break during an update, if the site is not in maintenance mode.

The discussion around this was at #2753681-33: Move CSRF header token out of REST module so that user module can use it, as well as any contrib module → however it seems that without updating the login controller the cut-over didn't ever really happen as intended.

Does this mean that we can only change the token used in the login controller now and have to wait for another two minor releases to come out, so the original is out of support?

From what I can tell (sorry if I'm off) but this token is still in use or potentially in use? So think we would have to deprecate it to be removed in D11.

From what I can tell (sorry if I'm off) but this token is still in use or potentially in use? So think we would have to deprecate it to be removed in D11.

This is the sticky wicket. The initial change would have properly deprecated this if the token were changed at the same time as the BC layer were added. Except, the BC layer was added and the use of the deprecated token did not.

So if we were to use the same deprecation procedure, then the BC layer stays, the token changes, and then in two minor releases (when the older one goes out of support) then the BC layer can be removed.

There's part of me that feels like that's a bit much, but it's the only real way to do this to be completely by the book. It would be nice to get some sort of official ruling on this by a framework maintainer.

Would agree with that.