test: refactor test-https-truncate

[Trott]

Checklist

• make -j4 test (UNIX), or vcbuild test nosign (Windows) passes
• commit message follows commit guidelines

Affected core subsystem(s)

test https

Description of change

• use common.mustCall() where appropriate
• Buffer.allocUnsafe() -> Buffer.alloc()
• do crypto check before loading any additional modules
• specify 1ms duration for setTimeout()

[Trott]

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

[benjamingr]

LGTM

[lpinca]

May I ask why alloc is preferred over allocUnsafe in a test?

[Trott]

May I ask why alloc is preferred over allocUnsafe in a test?

I don't feel strongly about it, but here's the thinking:

• If we use Buffer.alloc(), then we get a buffer with predictable contents. While the contents don't play a role in the test here, all things being equal, I prefer having repeatable, predictable tests over tests with unpredictable inputs involved (unless, of course, the purpose is to do something like fuzz testing).

• This is not performance-critical code, so the (small, in this case) performance hit of zero-filling is not a concern.

• The very name of Buffer.allocUnsafe() seems to suggest "Don't use it unless you need to and know what you're doing." We don't need it here, so...

Again, I don't feel particularly strongly about it, but it does seem to me that if we can use either alloc() or allocUnsafe() in a test without any real difference, then we should default to alloc(). (The situation is different in lib where it stands to reason that tiny performance hits can add up to significant performance issues for some use cases. I'm only talking about test here.)

[lpinca]

Yes, I'm fine with that, was just curious.

[lance]

Landed in 8bad37a