fix: cap sendInputEvent text length at n-1

[nornagon]

Description of Change

This fixes two bugs with sendInputEvent, detected by ASan.

1. The call to memset was not clearing the full buffer, as the size of each
   element of the array is 2 bytes, not 1.
2. This buffer is at some later point passed to string() as a raw char16
   pointer, which causes the length of the string to be computed by seeking for
   a null terminator. However, this results in an out-of-bounds access as we
   often fill all 4 characters of both text and unmodified_text with
   non-null values.

It looks like this code was inspired by
BuildCharEvent
in content/renderer/pepper/event_conversion.cc, so I've updated this to be a
little closer to that code. I think the upstream code also has this issue but
gets away with it because it doesn't set unmodified_text, so there's always a
\0 after text due to the struct layout.

I'm not sure if we actually need unmodified_text---the pepper converter does
not fill it in.

Further, we fill text from keyCode, which is a bit of an odd choice. The
value is supposed to represent the text that should be inserted, which for the
key code Escape is not "Esca". It's not clear to me what the "right" path
forward is here, but this at least prevents the OOB access.

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• tests are changed or added
• relevant documentation is changed or added
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes: Fixed an out-of-bounds access in WebContents.sendInputEvent.

[release-clerk]

Release Notes Persisted

Fixed an out-of-bounds access in WebContents.sendInputEvent.

[trop]

I have automatically backported this PR to "11-x-y", please check out #27853

[trop]

I have automatically backported this PR to "10-x-y", please check out #27854

[trop]

I have automatically backported this PR to "12-x-y", please check out #27855

[attritionorg]

@nornagon Does '2' as described represent a security risk?

[nornagon]

@attritionorg technically I suppose yes, but I'd rank it as very difficult or impossible to exploit, as the OOB access is only a couple of bytes wide, and into other data on the stack that is not very interesting. Further, this is only in the main process, which is ostensibly trusted code.

[attritionorg]

@nornagon Great, thank you for confirming!