Disable services until initial render of configuration

[Frode Nordahl]

Most of the software installed and managed by charms will not operate correctly until required charm relations have been established and configuration is rendered.

However, the packages installed by the charm often enable the service by default and the init system will make repeated attempts to start the service until it finally gives up.

This may leave units in a non-functional state since when the charm finally renders the config and attempts to (re-)start the service, the init system may have marked it as failed and refusing to start it.

The situation described above also leads to a lot unnecessary noise in the system logs.

A pattern has emerged in our reactive charms where the charm author explicitly mask services, prohibiting the init system from attempting to start them, until initial render of configuration has happened.

We should implement opt-in default handlers for this pattern in `layer-openstack` and `charms.openstack`.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/696464

[Frode Nordahl (fnordahl)]

Fix proposed to branch: master
Review: https://review.opendev.org/#/c/696465/

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/696464
Committed: https://git.openstack.org/cgit/openstack/charms.openstack/commit/?id=f3c61339ac69baeb7b3dc94ed3c9eed03200a40f
Submitter: Zuul
Branch: master

commit f3c61339ac69baeb7b3dc94ed3c9eed03200a40f
Author: Frode Nordahl <email address hidden>
Date: Thu Nov 28 08:43:05 2019 +0100

    Add default handler for ``config.rendered`` state

    Replace forward declaration of ``haproxy_enabled`` method in
    ``OpenStackCharm`` class with a ``full_service_list`` property
    that descendants override to add their specialities to.

    Needed-By: I510efbcc2d8b889fe5c41679c8ab391bf1374bd4
    Change-Id: I5b8839dc875e413ce3c6611f540fb4919ae86d70
    Closes-Bug: #1854313