`NetDriver` key handling is broken on Windows Terminal v1.18+

To repro simply run UI Catalog and press ESC a few times.

I found this while trying to track down what I broke in #2612.

I kept going back in my commit history to find where the odd behavior I was seeing didn’t happen. I eventually just tried v2_develop and discovered this was happening. So I tried it on develop too.

[j4james]

I don’t know the code base, so this is just a wild guess, but the code here looks suspicious:

https://github.com/gui-cs/Terminal.Gui/blob/db78fe28bce10fe6ae5d4c6062e8b4ef07f7b8fa/Terminal.Gui/ConsoleDrivers/NetDriver.cs#L198-L201

If you get into that branch, cki is going to be set to null, but isEscSeq is not reset to false. So the next time GetConsoleKey is called, if consoleKeyInfo.KeyChar is Esc again, you’re assumedly going to enter that branch with cki now being null. From there you call DecodeEscSeq with null, which in turn calls GetCharArray with null.

At least that’s what it looks like to me.

[tig]

@BDisp see my latest push to this PR.

There is a bug somewhere that is causing isEscSeq to be true with cki being null. I’ve added a defensive check for this as I’ve not been able to reliably reproduce it in a way that shows me what’s causing it.

Note, I discovered something else that indicates EscSeqUtils may need to be refactored.

If the user presses a key while the terminal is sending an esc sequence (e.g. a '[35` mouse move report), that key info is lost. The result of this is no keystrokes can happen while the user is moving the mouse.

As we move to a world where all drivers rely heavily on emitting and receiving escape sequences, we need EscSeqUtils to be very robust and flexible. It works pretty darn good right now (great job!) but it is fragile and brittle. It doesn’t help that the documentation for ANSI sequences and all the implementations are so sketchy.

I still haven’t figured out what I screwed up in #2612 that has broken netdriver in this regard, FWIW.