LG-15183: Associate user_id for reCAPTCHA result analytics of failed sign-in

[aduth]

🎫 Ticket

LG-15183

🛠 Summary of changes

Fixes an issue where the "reCAPTCHA verify result received" event does not correctly associate the user_id if the sign-in attempt is unsuccessful for a reason other than reCAPTCHA.

This happens because the user is not yet signed-in. For "Email and Password Authentication" events, we work around this by explicitly passing the user_id from the user associated with the given email parameter. The changes proposed here instead override the base ApplicationController#analytics_user to use this parameter-based user during the submission, so that all analytics logging will have that user associated.

📜 Testing Plan

Verify that both "Email and Password Authentication" and "reCAPTCHA verify result received" events include the user_id property of the user associated with the submitted email address:

1. Run make watch_events in a separate terminal process
2. Go to http://localhost:3000
3. Enter an email address associated with a user account (or not associated with an account, to verify expected nil user_id)
4. Enter a correct or incorrect password for that user account
5. Click "Sign in"
6. In the make watch_events process, observe events "Email and Password Authentication" and "reCAPTCHA verify result received" both have associated user_id, regardless if you entered a correct password for the account

[aduth]

These changes are necessary because the unsuccessful submission will result in a redirect back to the sign-in page, which counterintuitively keeps original_analytics.request.params[:action] == 'create' even in the processing of the #new action, since the action is processed as a result of the submission's redirect. Since user_id is expected to be nil on the "Sign in page visited" event, the previous implementation would raise an exception. These changes are to limit assertions to only analytics logged during #create.