Remove Cable Ready responses from User related controllers

[wandji20]

What? Why?

• Closes #
  This is the first part of moving away from Cable Ready in favor of Hotwire related to Replace mrujs with turbo #12794

• Since Turbo covers everything cable_ready does, we can safely move from cable_ready and mrujs to turbo.

This PR covers changes to the User Session, Password, Registration, and Confirmation Controllers.

What should we test?

The flow for user registration, login, password reset, and confirmation should be retained.

• Visit home page.
• Try to sign up with existing email address and observer error message.
• Sign up successfully.
• Logout and log in. Test error scenarios.
• Change password. Test error scenarios.

Release notes

Changelog Category (reviewers may add a label for the release notes):

• User facing changes
• API changes (V0, V1, DFC or Webhook)
• Technical changes only
• Feature toggled

Dependencies

N/A

Documentation updates

N/A

[mkllnk]

So cool!

We need some better testing instructions though. I'll edit them to let the testers know which functionality is affected.

[dacook]

Great, thanks for splitting this into a smaller PR.
Just a couple of things to check out:

[dacook]

Yay, ready to test!

[filipefurtad0]

What should we test?

The flow for user registration, login, password reset, and confirmation should be retained.

• Visiting the home page and attempting to sign up with existing email address triggers the expected error message:

• Signing up works as before, for a valid email address:
  -> after a confirmation email it is possible to log in to the new account

• Logging out and back in works fine

• Logging in directly to the /admin page, to test the a 401 Unauthorized scenario 🔴
  -> triggers the login modal, as expected
  -> after entering a customer (instead of admin credentials) logs in successfully but re-triggers the log-in modal. This differs from the previous behavior, where a flash message was displayed instead, please see below:

I think this would be a regression, as the modal is relevant to inform the user that access to that page is not granted. Also, the modal should not appear a second time.

• Changing password works as before.

• Attempting to change passwords with different passwords
  -> triggers the expected error

Summary

Everything looks great, except the 401 scenario. I think this usability regression should be prevented. Would you be up to improive this @wandji20 ? Moving to in progress, for now.