Investigate flaky parallel/test-tls-socket-close on Raspberry Pi

[Trott]

• Version: v8.0.0-pre
• Platform: pi1-raspbian-wheezy
• Subsystem: tls (test)

https://ci.nodejs.org/job/node-test-binary-arm/6752/RUN_SUBSET=3,label=pi1-raspbian-wheezy/console

not ok 168 parallel/test-tls-socket-close
  ---
  duration_ms: 2.557
  severity: fail
  stack: |-
    events.js:184
          throw er; // Unhandled 'error' event
          ^
    
    Error: read ECONNRESET
        at exports._errnoException (util.js:1029:11)
        at TLSWrap.onread (net.js:605:26)
  ...

@nodejs/testing @jBarz

[Trott]

If we can't get rid of T in this test, it might help to use common.platformTimeout() on line 23. (I want to be able to reproduce the problem before jumping to that conclusion, though.)

[Trott]

I am able to cause this and several other timing-related problems by running the test under load. The other problems seem more common but every once in a while I get something like this:

tools/test.py -j 32 --repeat 32 test/parallel/test-tls-socket-close.js 
=== release test-tls-socket-close ===                    
Path: parallel/test-tls-socket-close
events.js:184
      throw er; // Unhandled 'error' event
      ^

Error: read ECONNRESET
    at exports._errnoException (util.js:1028:11)
    at TLSWrap.onread (net.js:605:26)
Command: out/Release/node /Users/trott/io.js/test/parallel/test-tls-socket-close.js
[00:01|% 100|+  31|-   1]: Done     

EDIT: The 32 causes errors more often than not on my machine, but if you find that isn't so, try larger values.

[Trott]

Proposed fix in #11921