handle Ctrl-C explicitly in confirm prompt

[ericmarkmartin]

Summary

Resolves #11704

Replace uv-console's use of ctrlc::set_handler to exit the prompt with an explicit matching on the user inputting Ctrl-C. This is accomplished via console's read_key_raw, which is exactly like read_key except it returns an explicit value indicating a user entered CtrlC rather than implicitly raising SIGINT and returning an error.

Test Plan

[ericmarkmartin]

Took a brief stab at testing, but failed. Not sure how to test the behavior when we need the subprocess to be interactive in order to see the confirmation prompt. For reference, this is what I attempted to no avail (the snapshot looks like what happens if you answer the confirmation prompt with no).

#[test]
fn ctrl_c_install_confirmation_prompt() -> Result<()> {
    let context = TestContext::new("3.12");

    context.temp_dir.child("pyproject.toml").touch()?;

    let ctrl_c_file = context.temp_dir.child("ctrl_c");

    ctrl_c_file.write_binary(&[0x03])?;

    let file_handle = std::fs::File::open(ctrl_c_file)?;

    uv_snapshot!(context.filters(), context.pip_install()
        .arg("pyproject.toml") // triggers confirmation prompt because user probably wants `-r`
        .stdin(file_handle), @r###"
        "###
    );

    Ok(())
}

[ericmarkmartin]

I've added a test that seems to work using pty, which I get out of wezterm's pty implementation. One thing to note is that the read out of the pty is non-blocking so if our confirmation prompt changes and becomes smaller, the test will hang, which isn't great. Still thinking of ways to fix that.

Part of making the test workable was a drive-by change so that the confirmation prompt respects the global color setting

[ericmarkmartin]

Apparently the fix doesn't work on windows, so converting back to draft while I workshop a bit

[konstin]

Can you try forwarding the io error? The handler seems working, but i think the main thread panics too fast.

[ericmarkmartin]

Can you try forwarding the io error? The handler seems working, but i think the main thread panics too fast.

Forwarding it out of where? I think the main thread panics because we forward it out of the confirm function and unwrap the containing Result, no?

[konstin]

Besides the behavior changes to signal handling, we would ideally not have an .unwrap() call at all, usually we can just propagate the error to the caller through a thiserror derive enum variant.