Switch Node Linux binary builds back to GLX/xvfb

[mikemorris]

Switches Node.js Linux binary builds from OSMesa back to GLX/xvfb to remove a runtime dependency on libOSMesa.so.8 and allow libGL.so to be supplied at runtime by alternate implementations, like the NVIDIA proprietary drivers for rendering on hardware GPUs.

/cc @brunoabinader @springmeyer

[mention-bot]

@mikemorris, thanks for your PR! By analyzing the history of the files in this pull request, we identified @ChrisLoer, @jfirebaugh and @tmpsantos to be potential reviewers.

[mikemorris]

Per http://www.mesa3d.org/osmesa.html, it's my understanding that using OSMesa eliminates any dynamic linking of libGL.so, so simply statically linking libOSMesa.a likely wouldn't be a fix here.

I think the proper path forward (after this rollback) for a non-GLX interface for the Node.js bindings would be shipping EGL headless backend support in #7007, as libEGL.so could be supplied by either the NVIDIA drivers or Mesa.

[brunoabinader]

it's my understanding that using OSMesa eliminates any dynamic linking of libGL.so

Correct - given the constraints, it seems either GLX or EGL solutions would seem more appropriate 👍

I think the proper path forward (after this rollback) for a non-GLX interface for the Node.js bindings would be shipping EGL headless backend support in #7007, as libEGL.so could be supplied by either the NVIDIA drivers or Mesa.

Totally - on my tests in Desktop Linux using NVIDIA proprietary drivers, both GLX and EGL backends worked fine.

[brunoabinader]

@mikemorris this is what I have in mind: Separate Node builds, one in debug mode for running tests, and the other in release mode for generating the node packages: https://gist.github.com/brunoabinader/3cf3e636a3f95a9f0aa4e04f2125caa4

Is this feasible?