Revert "Make a noble effort at setting OS_CODE correctly."

[sam-github]

Revert change to the OS_CODE in the zlib header made in zlib 1.2.11. It
changes the binary format of the compressed data on MacOS. This has been
found to cause problems for test suites that used to be passing in 4.x
and 6.x, and that had assertions based on the expect compressed output.

Refs: madler/zlib@ce12c5c

Checklist

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

Affected core subsystem(s)

[sam-github]

Haven't tested on OS X yet, so its WIP, should get done today.

[sam-github]

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

Fix #12244

[sam-github]

Passed by hand on os x and linux, failed on os x without the revert patch.

[bnoordhuis]

I'm mildly -1 on this. For one, the test can fail when built against a shared zlib. For two, chopping up our in-tree copy like that is just... icky. I don't like the idea of floating patches that aren't strictly necessary.

[sam-github]

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

[sam-github]

Definitely a grey area. I don't think people should be relying on the output encoding, but we've found at least two instances where they were. I can let this sit and we can wait for more bug reports.

[jasnell]

I'm leaning in the same direction as @bnoordhuis on this.

[sam-github]

/fyi @rmg

[rmg]

I was willing to live with the yuck factor if it meant giving users a better experience, but the fact that this was already "broken" if someone switched between builtin and shared zlib is an even better argument.

I think the problems caused have been too few to warrant the cost of this bug compatibility. I would say sit on it for a little while longer, but it has already been 2 weeks since the initial report and there has only been 1 other instance in that time.

-1, we can re-open if we suddenly get a flood of new reports.

[MylesBorins]

Closing for now