Improve TPM DUK passphrase UX

[UndeadDevel]

Is your feature request related to a problem? Please describe. There are two issues IMHO:

1. Capslock doesn't work, but there is no warning, so if the user enters the passphrase using capslock for some characters during setup, thinking that those characters are now capitalized and then later during passphrase entry on boot enters those characters with Shift instead of capslock, the passphrase won't be accepted, because it's not the same.
2. When the wrong passphrase (for TPM DUK) is entered the op fails immediately, falling back to recovery shell. Have mercy! Give the user at least another couple of tries in case of mistyping (is known to happen occasionally)...otherwise the presumably much more complex Disk Recovery Passphrase needs to be entered or a reboot triggered, which is bad UX.

Describe the solution you'd like for 1.: either allow capslock under Heads or notify the user that capslock has no effect for 2.: if TPM DUK unlocking fails due to bad passphrase, allow the user to retry a couple of times (maybe twice, so three tries in total).

Describe alternatives you've considered Alternative for 1 is described above. For 2: I guess returning to the main menu would be a better alternative than dropping to the recovery shell, though that may not be desirable as it makes it too easy to retry passphrases indefinitely.

[UndeadDevel]

Had a situation again when I mistyped the TPM DUK passphrase but this time it didn't fall back to recovery shell for some reason (I still had to reboot from the main menu, but it was better UX-wise)...~~I'm not sure exactly what I did differently this time, but~~ I suppose the more important issue is CAPSLOCK, which is at least partially covered by #1486. Edit: I figured out where the inconsistency lies: when mistyping the TPM DUK passphrase after initiating "Default Boot" in the Heads main menu it will force the user into recovery shell; if mistyping it after initiating a "Boot one time only" boot from the OS boot menu option then it will allow going back to the menu. Ideally this inconsistency should be fixed, with the return to menu being the standard.

[tlaurion]

@UndeadDevel

I suppose the more important issue is CAPSLOCK

@UndeadDevel I really thought it would be easy to fix capslock, but it seems that we will need additional tooling to do this. One can expose for example the capslock leds, and/or see state of those lighs for keyboards having those leds... But in our case, we can expose the led but since EC is not toggling those leds because they actully don't exist, it seems we would have to interact with the tty to get the state of modifiers applied to see if capslock is triggered for next input. That would be through kbd tool, and or would need a new minimalist c tool being made to address this, inteacting with ioctl and reporting state to produce a warning and then add that test prior of all user input in code.

When the wrong passphrase (for TPM DUK) is entered the op fails immediately, falling back to recovery shell. Have mercy!

The reasoning behind that is that the TPM is actually doing the rate limiting and proposing to the user to do more then one input will trigger that rate limiting, eventually putting the TPM in a locked state where unsealing will produce a TPM error. Will create a loop around that, that is really easy to do. But that would need tome added warning and/or error parsing from unsealing to get TPM locked state errror. Rebooting is necessary to reset that locked state.

Just wanted to let you know I've been thinking about this issue, even tried a couple of things mostly for Caplsock wanting to fix both at the same time, but it will be fixed seperately where capslock as of now is missing an elegant way to fix.