test,console: add testing for monkeypatching of console stdio

[Trott]

lib/internal/console/constructor.js contains setters for console._stdout
and console._stderr but these setters are not used in our tests or in
Node.js core. (This is confirmed by our nightly coverage reports.)

Add a test to check monkeypatching _stdout and _stderr on a console
object.

Version 2.6.9 of the very-popular npm module debug used this
monkeypatching in its code. No other version did and they are now at
version 4.something. It is not inconceivable that we would want to
change the setters to throw rather than work. Given that this has seen
use in the ecosystem, I'm inclined to leave the functionality in place.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• commit message follows commit guidelines

[nodejs-github-bot]

@Trott build started: https://ci.nodejs.org/blue/organizations/jenkins/node-test-pull-request-lite-pipeline/detail/node-test-pull-request-lite-pipeline/2846/pipeline

[Trott]

CI: https://ci.nodejs.org/job/node-test-pull-request/21387/

[BridgeAR]

The part where debug uses it seems to be a internal debugging functionality? Since it was added in the release commit I expect it to be added by accident by using e.g. git commit add ..

A user of debug v2.6.9 would not trigger this part.

I would therefore go ahead and deprecate or remove the setter (the latter only with a clean CITGM run and no entries with https://github.com/nodejs/Gzemnid).

[Trott]

The part where debug uses it seems to be a internal debugging functionality?

That might still be an argument for keeping it. Someone, at one point, found monkey-patching it useful.

My opinion on this isn't a strong one, though, and I'd be fine with checking Gzemnid, changing the setter so that it throws, and running CITGM as an alternative. I worry that would stall, though, so I'd prefer to leave this open (and even land it) while that other process proceeds.

[Trott]

Landed in 6913bd1 so we have a test for the setters. Will open a semver-major to change this behavior and we'll see how that goes.

[Trott]

Will open a semver-major to change this behavior and we'll see how that goes.

Actually, I think I'm not going to do that. We don't seem to prevent this sort of thing generally and there's no existing error code that I can find that seems to fit, suggesting we may not really do this at all? I'm not opposed to doing it, but it seems like a potentially significant departure and I'm inclined to leave well-enough alone.