Fixes #2745 - NetDriver key handling is broken on Windows Terminal v1.18+

[tig]

Fixes #2745 (see also this WT issue: microsoft/terminal#15693)

This PR comments out the code in NetDriver that attempted to use ESC sequences to determine if the terminal has been resized. This code is naive and doesn't actually work: If IsTerminalWithOptions is true we send the "query size" ESC sequence every 10ms and WT 1.18+ dutifully responds. Thus all other keyboard input is swamped.

All of this code will be significantly reworked in v2 (as part of #2612).

@BDisp - You put this code in for a reason so I'm a little leery about simply disabling it as I've done here. Do you remember what scenario this may break (e.g. is it some oddball linux/docker scenario or some other terminal beyond Windows Terminal?).

Pull Request checklist:

• I've named my PR in the form of "Fixes #issue. Terse description."
• My code follows the style guidelines of Terminal.Gui - if you use Visual Studio, hit CTRL-K-D to automatically reformat your files before committing.
• My code follows the Terminal.Gui library design guidelines
• I ran dotnet test before commit
• I have made corresponding changes to the API documentation (using /// style comments)
• My changes generate no new warnings
• I have checked my code and corrected any poor grammar or misspellings
• I conducted basic QA to assure all features are working

[tig]

I've also pulled #2731 into this. Thanks @tznind .

[BDisp]

@BDisp - You put this code in for a reason so I'm a little leery about simply disabling it as I've done here. Do you remember what scenario this may break (e.g. is it some oddball linux/docker scenario or some other terminal beyond Windows Terminal?).

Yes, I know why I put that. It's was to use on Linux because it don't recognize Console.BufferWidth and the Console.BufferHeight and the escape sequence is querying for terminal resize changes. In Linux this is natively fast but on a pseudo terminal on Windows, even with Windows Terminal it take longer to process them. But I also realized the query only return the windows size and not the buffer size. So, that can be ignored.

[tig]

@BDisp - You put this code in for a reason so I'm a little leery about simply disabling it as I've done here. Do you remember what scenario this may break (e.g. is it some oddball linux/docker scenario or some other terminal beyond Windows Terminal?).

Yes, I know why I put that. It's was to use on Linux because it don't recognize Console.BufferWidth and the Console.BufferHeight and the escape sequence is querying for terminal resize changes. In Linux this is natively fast but on a pseudo terminal on Windows, even with Windows Terminal it take longer to process them. But I also realized the query only return the windows size and not the buffer size. So, that can be ignored.

My test results:

• In WT v1.18 - Works fine

• In Terminator via WSL and this PR works fine:
  

• In xterm via WSL this PR works fine:
  

• ConEmu (not WSL)

  • Resizing does not work (but doesn't work with develop either)

[BDisp]

As I said, when I implemented that was to get the terminal buffer size (to use with the EnableConsoleScrolling but it only get the terminal size) and not the the terminal size. Linux read the terminfo to get the LINES and COLS and the mainloop invoke a event when their values changes and it not need the escape sequence for that, glad you removed it. On ConEmu I didn't test it yet.

[tig]

Last call before I merge this fix. I'm pretty sure it doesn't break anything else, but I'd feel much better if others had tested it.

[BDisp]

@tig please see my review, thanks.