Stdin read-ahead in Emacs mode

[Rudi Horn via Bug reports for the GNU Bourne Again SHell]

I have been trying to diagnose an issue with LSP over TRAMP in Emacs, 
which I have documented in two github comments 
(https://github.com/emacs-lsp/lsp-mode/issues/2709#issuecomment-3311705879). 
The essential problem I have been encountering, is that the stdin in is 
used to pass commands to the shell, and then input to a process spawned 
by the shell. Some of the bytes meant for the newly spanned process are 
consumed by bash read-ahead and thus don't make it to the spawned process.

This behaviour only happens when readline is disabled, which seems to 
happen either with `--noediting` or when `INSIDE_EMACS` and `TERM=dumb 
are set. In this case the `getc_with_restart` function is used, and this 
in turn uses `read(fd, buf, 128)`, which may consume additional bytes. I 
believe the `readline` implementation always only calls `read(..., 1)`. 
Unfortunately that also comes with a performance impact.

This feels like it is at least partially a bash problem, and I'm 
wondering if finding a way to resolve it would make TRAMP more reliable 
in general. I assume using readline is not the correct option, as this 
would interfere with emacs. It seems like there should be a way to allow 
the no readline behaviour to prevent read-ahead, and maybe this should 
be the default behaviour unless some specific circumstances are met 
(e.g. reading from an actual file rather than a pipe, or only when not 
using stdin). Is anyone here familiar with the Emacs specific behaviour 
in bash?

Thanks,
Rudi Horn