Solve problem with unreachable sites due to ddev-router config fail, fixes #2648

[rfay]

The Problem/Issue/Bug:

#2648 : In ddev v1.16.0 and v1.16.1, a ddev start might result in a site that was unreachable; the newly started site would get "503: No ddev back-end site available."

How this PR Solves The Problem:

It turns out that this was timing related, but more importantly,

• the listener (-watch) docker-gen process creates a script which is then run to create the nginx configuration
• However, the script is not recreated if docker-gen does not see that it changed
• However, the generated script had hostnames in it (container names) but it did not include the ports from HTTP_EXPOSE or HTTPS_EXPOSE. So if those came through in separate events, docker-gen would read the later events but decide that because the generated script did not change, it did not need to be recreated (and the script didn't get run... so the nginx configuration was not updated)

This also

• Improves the healthcheck to detect whether the /etc/nginx/conf.d/default.conf has been properly generated
• Cleans up the healthcheck in general
• Provides a default.conf that is more appropriate than the one put there by the nginx package (and includes healthcheck)

Manual Testing Instructions:

• If you do not have the ddev binary build with this PR, then add this file as ~/.ddev/router-compose.nginx.yaml (router-compose.nginx.yaml in your global .ddev directory, the one in your home directory), then ddev poweroff and do the normal testing that was earlier able to create the problem:

version: '3.6'
services:
  ddev-router:
    image: drud/ddev-router:20201124_router_fails_to_expose

• Otherwise, test with the ddev binary from this PR
• Make sure to test with the varnish recipe from ddev-contrib and other 3rd party services.
• The script linked in Can't access more than 2 ddev sites at the same time (after updating to v1.16.0, MacOS) #2648 may induce the failure described there, so try it.

Automated Testing Overview:

This seems to be timing related and dependent on docker's state somehow and difficult to test.

Related Issue Link(s):

#2648

Release/Deployment notes:

[rfay]

I note that when I use the varnish 3rd party service with this PR the healthcheck stanza does not get generated in the ddev-router nginx config (default.conf).

Oddly, it's not a problem with the solr service.

[rfay]

I tried the script from #2648 and ran it repeatedly with this ddev version and was no longer able to demonstrate the problem.