Revert "Uppercase the auth factor token in input value to match the email casing. (#7094)"

[damz]

This reverts #7094, as it triggered an issue on Android where the first input on the field (either a keyboard input or a copy/paste) would get swallowed.

See discussion at #7094 (comment)

[mozzius]

I think the better solution would be to make it a controlled input, so rerendering doesn't wipe it - no?

[damz]

@mozzius Unless the input loop is synchronous with the rendering (which I don't think it is on any platform, including the web), controlled inputs that are editable sound like a bad idea. @gaearon had a discussion about that last year with the react-native team.

[mozzius]

I'm well aware - the specific issue was an iOS autocorrect error which was fixed in the react native new architecture (which we will be migrating to soon). If we've got a specific case where a controlled input provides better UX it's fine to use them - especially in this android-only case

[damz]

I don't see how you would do a non-racy controlled input. You are in general not going to be able to avoid swallowing some input that might happen on the native side while you are executing the rendering process on the Javascript side?

[damz]

(I rebased this to see to see if the false positive CI check "No manual yarn.lock edits" would go away)

[damz]

(Yes, this check is broken: it starts with the yarn.lock from the base branch, but then compares result of yarn install with the contents the yarn.lock of the PR branch before the merge. It should merge first, before reverting the yarn.lock to the base branch version.)