Fix the following build error by putting #if guards around the
variables:

    ../src/node.cc: In function 'void node::ParseArgs(int*,
    const char**, int*, const char***, int*, const char***)':
    ../src/node.cc:3037:7: error: 'SSL2_ENABLE' was not declared
    in this scope
           SSL2_ENABLE = true;
           ^
    ../src/node.cc:3039:7: error: 'SSL3_ENABLE' was not declared
    in this scope
           SSL3_ENABLE = true;

Fixes: nodejs/node-v0.x-archive#8645
PR-URL: nodejs#3825
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Johan Bergström <bugs@bergstroem.nu>
Reviewed-By: James M Snell <jasnell@gmail.com>

This is a roll-up release that includes all changes to npm since 2.13.4.

PR-URL: nodejs#3684
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>

As part of the fix for logjam, node was upgraded to a
level of openssl which rejects connections to servers that
are using keys smaller than 768 bits. It is still possible,
however, to create a server that uses a smaller key size
and and older client may be able to connect to it.

This PR moves us to a secure by default stance on the
server side as well, preventing the creation of a server
using a dhe key size less than 768. This can be overridden
with the command line option which is also added.

It is derived from

nodejs@9b35be5

which was landed in later io.js/node versions but makes
the limit 1024.  This PR uses the smaller limit in order
to meet the recomendations for logjam while matching was
was done on the client side in openssl to minimize the
potential impacton users.

The command line option will only be documented in the
release notes and will not be added to the tls
documentation.  The goal is that people who are
upgrading are aware and can use the option if they
run into issues, but otherwise the option is not
visible/used.

PR-URL: nodejs#3890
Fixes: nodejs/Release#49
Reviewed-By: Myles Borins <mborins@us.ibm.com>
Reviewed-By: James Snell <jasnell@gmail.com>
Reviewed-By: Rod Vagg <r@va.gg>
Reviewed-By: Shigeki Ohtsu <ohtsu@iij.ad.jp>

Original commit message:

    api: introduce SealHandleScope

    When debugging Handle leaks in io.js we found it very convenient to be
    able to Seal some specific (root in our case) scope to prevent Handle
    allocations in it, and easily find leakage.

    R=yangguo
    BUG=

    Review URL: https://codereview.chromium.org/1079713002

    Cr-Commit-Position: refs/heads/master@{nodejs#27766}

Should help us identify and fix Handle leaks in core and user-space code.

NOTE: Works only in Debug build now, but is still better than nothing.

Helps to find Handle leaks in Debug mode.

Ref: a5244d3 "deps: backport 1f8555 from v8's upstream"

The call to node::Environment::GetCurrent(Isolate*) makes the call to
v8::Isolate::GetCurrentContext(). Doing so creates a new handle that was
bubbled to the SealHandleScope.