[BUG] npm module __virtual__ takes 3 minutes to run when behind corporate firewall/proxy

[danieljennings]

Description
When the npm.py module loads via __virtual__, it executes the npm --version command:

salt/salt/modules/npm.py

Lines 39 to 51 in 2d17209

	def _check_valid_version():
	"""
	Check the version of npm to ensure this module will work. Currently
	npm must be at least version 1.2.
	"""
	# Locate the full path to npm
	npm_path = salt.utils.path.which("npm")
	# pylint: disable=no-member
	res = salt.modules.cmdmod.run(
	"{npm} --version".format(npm=npm_path), output_loglevel="quiet"
	)

Per this bug (and my empirical experience) that command will take 3 minutes to run when behind a corporate firewall that prevents the "update notifier" from connecting to whatever web servers.

Because it's called from inside of the __virtual__, this causes any command that loads all of the modules (i.e. even an unrelated-to-NPM salt-call) to take 3+ minutes to run (and eventually timeout inside the update notifier).

The simplest fix would be to add the env var NO_UPDATE_NOTIFIER=1 to _check_valid_version's cmdmod.run call. I recognize that there are other npm commands inside of npm.py that will run into the same problem, but I'm particularly interested here because this behavior inside of a __virtual__ method is especially problematic due to running at module-load-time even if you don't use any of the NPM module features of Salt (since it's activated by virtue of just having an 'npm' executable found). There is supposedly a command line argument `--no-update-notifier' but I've seen reports online of it not working and have only confirmed that the environment variable fixes the problem.

I've included a version report but this behavior is seemingly common across all platforms.

Versions Report

salt --versions-report

``` Salt Version: Salt: 3002

Dependency Versions:
cffi: 1.12.2
cherrypy: 17.4.1
dateutil: 2.8.0
docker-py: Not Installed
gitdb: 2.0.5
gitpython: Not Installed
Jinja2: 2.10.1
libgit2: Not Installed
M2Crypto: Not Installed
Mako: 1.0.7
msgpack-pure: Not Installed
msgpack-python: 1.0.0
mysql-python: Not Installed
pycparser: 2.19
pycrypto: Not Installed
pycryptodome: 3.9.8
pygit2: Not Installed
Python: 3.7.4 (tags/v3.7.4:e09359112e, Jul 8 2019, 20:34:20) [MSC v.1916 64 bit (AMD64)]
python-gnupg: 0.4.4
PyYAML: 5.3.1
PyZMQ: 18.0.1
smmap: 2.0.5
timelib: 0.2.4
Tornado: 4.5.3
ZMQ: 4.3.1

System Versions:
dist:
locale: cp1252
machine: AMD64
release: 2019Server
system: Windows
version: 2019Server 10.0.17763 SP0

</details>

[xeacott]

Thank you for submitting this @danieljennings would you like to open a PR with your fix? Looked into it a bit, and it does appear that setting that var has fixed many others' issues.