When using mod_systemd on a system with a systemd httpd service of type notify, we have encountered a scenario where the command `systemctl reload httpd` never returns.  In this case, systemd continues to report the service as reloading, even though httpd respawned all of its server processes.

I have tracked the problem down to the way in which an `ExtendedStatus Off` directive in the local configuration is interacting with the code introduced here: http://svn.apache.org/viewvc?view=revision&revision=1802251 .  The general sequence of events is:

1. User runs `systemctl reload httpd`.
2. systemd forks off an `httpd -k graceful` process, which exits successfully.
3. mod_systemd's systemd_pre_config hook sends a notification to systemd that httpd is reloading, then sets ap_extended_status.
4. While reloading its configuration, httpd responds to an `ExtendedStatus Off` directive by clearing ap_extended_status.
5. Subsequent calls to mod_systemd's systemd_monitor hook short-circuit when they see that ap_extended_status is cleared so httpd stops sending status updates to systemd.
6. systemd indefinitely reports httpd's state as reloading because it never receives a READY=1 notification from mod_systemd's systemd_monitor hook.
7. The `systemctl reload httpd` command never exits.

I would expect httpd tell systemd when it finished reloading its configuration regardless of the state of ap_extended_status.  I believe sending a notification such as "READY=1\nSTATUS=ExtendedStatus is disabled." before short-circuiting when ap_extended_status is cleared should resolve the issue, but I haven't had an opportunity to setup a build environment to confirm.