Stop the JSON API before plugins delete their resource providers

[jolavillette]

One commit, already open standalone as RetroShare#366. Proposing it here as well on purpose — see the last section for why the duplication is deliberate.

The defect

RsServer::rsGlobalShutDown() stops the JSON API almost last, after stopPlugins().

A plugin that registered a JsonApiResourceProvider deletes it in its stop(), but the running restbed service still holds the restbed::Resource objects that provider returned, and their handlers capture it — JsonApiServer::run() publishes them once at thread start and the service keeps them for its whole lifetime. Any request served between stopPlugins() and the fullstop() at the end of the function therefore dereferences freed memory.

The window is not theoretical: everything in between — UPnP teardown, the auto-proxy shutdown, all registered service threads, the RsServer tick thread and the per-peer streamers — can take tens of seconds, and a web interface polls throughout.

This moves the fullstop() to the top of the function. Two details worth noting:

• it also keeps an API client from touching the configuration after ConfigFinalSave(), which runs a couple of lines below;
• it stays outside the wasReady branch, because retroshare-service and Android start the JSON API before login, so a shutdown from that state has to stop it too. That is why the call cannot simply be hoisted into the existing block.

Why it belongs in this PR

The defect is only reachable once a plugin can register a resource provider — which is exactly what this PR enables. Before it, no plugin in the tree has access to RsJsonApi, so the code path does not exist.

It also closes a merge-order trap. RetroShare/RetroShare#3289 no longer restarts the JSON API from FeedReaderPlugin::stop(); that restart used to be what made deleting the provider safe, and this change is what replaces it. #3289 already declares a hard dependency on this PR — without it the plugin does not even compile, since RsPlugInInterfaces::mJsonApi would not exist. Carrying the shutdown fix here therefore makes it impossible to merge #3289 without the protection, instead of relying on someone reading a note about merge order.

On the duplication with RetroShare#366

RetroShare#366 stays open as a fallback: if this PR is delayed or dropped, the fix should still reach master on its own. Whichever lands first, the other becomes a no-op — the patch is identical, so git merges it without conflict — and I will close RetroShare#366 once this one is in.

Not build-tested. The MINGW64 workflow in this repo fails at "Checkout submodules" on every branch including master (it lists the super-project's submodules, which do not exist here), so its red mark is unrelated.

[defnax]

this not mergeable i saw it today

[jolavillette]

#6 merges cleanly — it is a fast-forward on top of api-for-plugins, one commit, no conflict. I verified it locally with git merge-tree as well as on GitHub, which reports MERGEABLE.