Add an endpoint to check connectivity to WOPI server

[meven]

The endpoint is accessible at /hosting/wopiAccessCheck

You send it a POST with input json:
{
"callbackUrl: ""
}

For instance:
curl -ki https://localhost:9980/hosting/wopiAccessCheck --header "Content-Type: application/json" -d '{"callbackUrl":"https://cool.local"}'

Returns json such as:
{
"status": 0,
"details": "OK"
}
With status and details giving hints to what went wrong if it did.

The callbackUrl needs just to be an HTTPS endpoint, it does not need to be the wopi service but can be only a healthcheck url for instance.

Change-Id: Ibdef0bbf0d2fd98e3d293a06dfcfc79478d618e5

cc @juliushaertl

Superseeds #4353

[mmeeks]

Good first cut - glad it works; needs re-working =) Thanks!

[meven]

The code is now ported to use async requests, but lacks detailed error reporting, cool internal API does not surface hostname errors, connection errors.

[vmiklos]

1. CI still needs to pass

2. I see that the PR has many commits, with commit messages that suggest you would squash this before merging. But if you do so, you'll get a quite large commit. It would be nice to split this to pieces: A) the net/ infrastructure you add (e.g. add socket to the connect fail callback) B) add the new endpoint with a single detected problem C) add the rest of the problems

3. I see that all the sync poco network code is gone, good.

4. The sync poco DNS code is also gone, good.

5. For something as simple as a JSON dictionary with a single entry, I would suggest to use escapeJSONValue() and build the reply manually, no need to go via poco JSON.

[meven]

2. I see that the PR has many commits, with commit messages that suggest you would squash this before merging. But if you do so, you'll get a quite large commit. It would be nice to split this to pieces: A) the net/ infrastructure you add (e.g. add socket to the connect fail callback) B) add the new endpoint with a single detected problem C) add the rest of the problems

Now split in three first is A, the two seconds are C (mostly optional just code improvement) and the fourth commit is B, the actual endpoint.

5. For something as simple as a JSON dictionary with a single entry, I would suggest to use escapeJSONValue() and build the reply manually, no need to go via poco JSON.

Taken care of. Thanks.

[vmiklos]

Looks reasonable to me, I think you did address the points from the previous round. I left some inline comments for nits, but it's fine to not block on those, this PR had many iterations already.

Please wait with merging till you also get a review from @mmeeks . Thanks.

[vmiklos]

OK, CI is green, that's promising.

[mmeeks]

Ok - this is a lot better, looks async - which is nice ;-) and I guess will really help if we can get the Nextcloud (and other integration) side working nicely - with some SDK documentation for the test end-point and so on :-)

There is a follow-on fix there that would be good to have.

Thanks Meven, Miklos & all.

[meven]

Ok - this is a lot better, looks async - which is nice ;-) and I guess will really help if we can get the Nextcloud (and other integration) side working nicely - with some SDK documentation for the test end-point and so on :-)

Documentation is my next step and informing Julius.

[juliusknorr]

Very nice to see this merged, thanks a lot.

I started a first draft PR to integrate with richdocuments (nextcloud/richdocuments#4361).

One thing I noticed would be that we have not reliable way to detect if the collabora server supports this check endpoint. Can we maybe expose it in /hosting/discovery similar to how it is done for capabilities: