REPL: use @async to run repl keymap etc. not @spawn :interactive

[IanButterworth]

The execution of regular user input happens outside of this scope, but if the user pastes in multiple prompts then those prompts are executed within these tasks.

On a system with no interactive pool, but a > 1 default one, @spawn :interactive has free reign to schedule onto any :default thread. (Perhaps it shouldn't and just spawn onto 1??)

Some user code doesn't like being run on threads other than the main thread, like GLFW, so weird errors can happen when code is pasted in that doesn't happen otherwise, so this reverts these back to @async.

The main task is already sticky for many reasons, so I don't think this is a loss.

[vtjnash]

Some user code doesn't like being run on threads other than the main thread

We previously defined that all user code executes on the original root Task (because some libraries get unhappy if you aren't running them on the main Task). Did that get broken here? There is no reason this should not be using @spawn, since all execution and printing should be managed via Channels back to the frontend Task.

[IanButterworth]

During bracketed paste that doesn't happen

julia/stdlib/REPL/src/REPL.jl

Line 1645 in 76687a2

@invokelatest LineEdit.mode(s).on_done(s, LineEdit.buffer(s), true)

[vtjnash]

That is not user code though. The user code happens later:

julia/stdlib/REPL/src/REPL.jl

Line 1233 in 76687a2

response = eval_with_backend(ast, backend(repl))

[IanButterworth]

This isn't right, I've opened an issue on the 1.12 milestone with @vtjnash's suggestion from slack #57742