bug#39687: 26.3; Add customize-variable option for not locking keyboards

[Logan Perkins]

In GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.11)
of 2020-01-28 built on gentoo-server
Windowing system distributor 'The X.Org Foundation', version 11.0.12005000
System Description: Gentoo Base System release 2.6

This is a feature request more than a bug report. When using the
built-in server (either via `emacs --daemon` or `server-start`) +
emacsclient, use of the minibuffer from one client completely blocks
other clients (they can't even quit until the mini buffer finishes).
This is governed by calls to
`temporarily_switch_to_single_kboard(struct frame *f)` in `keyboard.c`.

If I understand correctly, there are two reasons for locking other
clients while the minibuffer is in use. First, the input for the
minibuffer is stored in a single global variable; while enabling
recursive minibuffers is possible, bottom line is there can only be *one*
active mini buffer at a time. Locking secondary inputs reduces the
potential for confusion with fighting over the minibuffer.

Additionally, sometimes there is something which requires a user
response (such as confirmation on killing a modified buffer), and
resolving that is simpler if the state isn't changing in the background.

On the other hand, even with a confirmation box open, a user can switch
away from the minibuffer and continue changing state (potentially even
opening a recursive minibuffer), so I don't think the second case is
sufficient cause to disallow multi-keyboard mode when the minibuffer is
in use.

As for the first issue, I don't think the present behavior is clearly
best, as it doesn't *ignore* secondary keyboard input, it *queues*
it, executing it in one block when the minibuffer ends. This can cause
unexpected issues for novice users. Also, the inability to even close
the client (short of SIGTERMing it) is not ideal.

I've gutted the
`temporarily_switch_to_single_kboard(struct frame *f)` in `keyboard.c`
on a test system, and successfully used it with multiple people sharing
a single server instance (on a joint project), and it works reasonably
well. I'd like to propose adding a customizeable variable in the
`minibuffer` group which disables locking the other keyboards. Ideally,
the other clients should get a "minibuffer in use" message in their
minibuffers so users can see when someone is using the minibuffer.

I am happy to work on this, and submit patches for it, but would
appreciate some advice before I start.

Is there some further reason to lock the keyboard that I haven't
considered?

I think it's better to use the customizeable variable to prevent the 
call to
temporarily_switch_to_single_kboard, rather than have that function not
do what it's name implies it does. Should I intercept all calls to it
based on one new variable? Or should I split general minibuffer use
from confirmation uses, and so on? (Looks like 3-4 different places
it's called in the source).

Should I make the behavior depend on some elisp function? I think that
might be the easiest way to support the "minibuffer in use" message and
the like, but I'm not sure what the downside would be.

Is it a waste of time for me to submit patches related to this feature?
If there's zero interest in adding this, or it would be less work for
someone else to write it than review my patches, I won't waste your time
sending them.

Regards,
Logan Perkins