Make nanonext compatible with existing NNG 1.5.2 release

[shikokuchuo]

NNG is essentially feature-complete and stable (although there are interesting 3rd party open-source extensions). nanonext was compatible up until v0.5.1 when Garrett D'Amore author of NNG implemented nanomsg/nng@722bf46 to make aio more efficient for a single-threaded language binding such as R.

It wouldn't be too difficult to re-implement the solution used previously with some notable improvements, such as a central shared mutex. This would be slightly less performant, but for applications such as crew, this would be inconsequential.

This can be implemented via a compile time define - using the 'fast path' if the library supports, or a 'compatibility mode' for existing library releases.

This would address concerns such as #6 as it will realistically take quite some time for a new NNG release to make it into distro repos, and existing LTS repos with mostly NNG 1.5.2 release can be very long-lived.

An env var can be used to allow the user to select what to do if there is a suitable system lib. Question then would be whether to make the bundled NNG default, or an older system library. Usually the system lib would take precedence, but most end-users would benefit from the improvements in the newer library. It could be said that those in settings which require the system lib would know to set the env var as appropriate. Any thoughts @wlandau?

[wlandau]

Thanks for looping me in. I think the bundled NNG would make a good default because it is a nudge towards consistency across different user installations. Having that consistency will make our jobs easier when folks ask for help. Also, some users may be running crew workflows on ancient on-prem clusters where every upgrade is a delicate negotiation with a sys admin. It would be an easy process for the user to just install nanonext in an renv library for a project.

[shikokuchuo]

As of nanonext 0.8.3.9008, the back compatibility is fully-implemented. Thanks for the insight - as a consequence, I am going to update the docs to recommend that users install the bundled libraries as default.

Where there are existing system libs installed, this can be enforced by setting a NANONEXT_LIBS env var.

The configure logic is still set up to respect system libs for now as (i) libnng-dev is not that common and unlikely to be installed by default, so it would have to be a conscious decision if people do it anyway (and despite the recommendation) and (ii) people may be using nanonext with native programs or other language bindings, in which case it would be safer to use the same library version.

In any case, I see this as quite an important update in bringing nanonext (and consequently, mirai, crew etc.) to as wide an audience as possible - especially for those in environments where using a non-release library would be prohibited.

[shikokuchuo]

A follow-on note now that NNG 1.6.0 has been released - the current development version of nanonext already bundles this source (as will the next CRAN version).

The package will continue to use an installed system library (in the standard filesystem locations) where available by default, only building the bundled source where necessary. Setting the NANONEXT_LIBS env var will continue to ensure the bundled library version is always built and used.