Review use of handlers included from "community" modules

[Matt-Yorkley]

From #110 (mkllnk):

I just provisioned our new staging server with this. Somehow the nginx role didn't recognise the change and didn't reload nginx. But after reloading manually, it's now using HTTP/2, great!

We should watch that nginx role. It's not a problem here though.

There's a couple of places where we use notify: and call the restart nginx handler, which is present in the community module jdauphant.nginx, and it seems like it is not actually being triggered. I think I encountered something like this before when trying to call a handler from our zzet.rbenv module and it didn't work.

We call the restart nginx handler in roles/webserver/tasks/main.yml as part of the provision.yml playbook without a corresponding entry in roles/webserver/handlers/main.yml, and it happens at a point in the playbook before the jdauphant.nginx module is included...

Within the deploy.yml playbook we also call the restart nginx handler a couple of times, but in that instance we have our own handler for restart nginx explicitly defined in roles/deploy/handlers/main.yml.

After a bit of investigation it seems like there are some issues with calling handlers from includes in ansible, in that the includes are only added when they are called, so their handlers are not globally available when running a playbook. https://github.com/ansible/ansible/issues/13485

We need to investigate this a bit more at some point and I think either make some explicit include calls to make sure those handlers are available where they are needed, or making sure we always have our own restart nginx handler available. There may also be other examples where this is an issue that we have missed.

[Matt-Yorkley]

More info: the copy init scripts files task that updates nginx config (mentioned by mklink in the original quoted comment) looks like the only place where we rely on this handler being present from jdauphant.nginx, our other uses are either within the jdauphant.nginx module itself, which is fine, or in deployment, where we have our own handler for it explicitly defined.