Forward run stdin via blocking read instead of polling available()

[jozanek]

Fixes #882.

Root cause

bloop run never delivered usable stdin to the forked application, and it broke on two layers:

• Server side — Forker forwarded stdin with a 50ms poll loop gated on opts.in.available() > 0. On the CLI path opts.in is nailgun's NGInputStream, whose available() returns 0 while data is in flight, so the loop never read — and never drove nailgun's demand protocol, so the server never even asked the client for input.
• Client side — the nailgun client (the external, unmaintained scala-cli fork of snailgun) read stdin with readLine() and forwarded each line without its newline, so the forked app's readInt/readLine/Scanner never saw a delimiter and blocked forever. It also NPE'd on EOF (line.length() was checked before line == null).

Changes

• Forker: replace the available() poll with a blocking read on a monix Task run on ExecutionContext.ioScheduler (the same blocking-I/O idiom used by BspServer/TestServer). This drives nailgun's demand protocol so the server actually requests and reads stdin.
• Drop the external snailgun dependency (unmaintained, no release since 2023) and replace it with a minimal, bloop-native nailgun client under bloop.rifle.internal.nailgun, trimmed to what bloop uses (daemon-thread path only, BloopRifleLogger directly). Its stdin forwarder sends each line with its newline and handles EOF. Adapted from snailgun (Apache-2.0, attributed in-file).
• Remove the now-unused BloopRifleLogger.nailgunLogger adapter.

Verification

• RunSpec.canRunApplicationThatReadsStdinWithoutAvailableBytes: a regression test using an InputStream whose available() always returns 0 (simulating NGInputStream). Fails on the old poll loop (15s timeout), passes on the blocking read.
• End-to-end: bloop run of an app doing println(StdIn.readInt() + StdIn.readInt()) now reads 1/2 and prints 3 (previously hung indefinitely).

[jozanek]

@tgodzik feel free to rerun, should not be connected to my changes.

[tgodzik]

I wonder whether we could reuse any of the monix utilities instead of using Threads directly.

ExecutionContext.ioScheduler.scheduleWithFixedDelay(duration, duration) { wouldn't block as well?

[jozanek]

updated

[tgodzik]

Were you able to confirm that it works when using bloop run ? It seems to not read anything at the moment with the example:

import scala.io.StdIn

@main def hello(): Unit =
  val x = StdIn.readInt()
  val y = StdIn.readInt()
  println(x + y)

[jozanek]

Hey Tomek! You are right, the test wasn't sufficient. The issue is in snailgun, but since it is not maintained anymore, I am thinking about moving it completely under bloop (500 LOC) and then try to reduce it as much as possible.