Store the notification START event where the END never arrives

[ponmeloco]

Problem

The same as statusengine/worker#42, for this worker: where a broker module such as mod_gearman distributes notifications, statusengine_host_notifications and statusengine_service_notifications stay empty. mod_gearman answers NEBTYPE_CONTACTNOTIFICATIONMETHOD_START (604) with NEBERROR_CALLBACKOVERRIDE, Naemon skips running the command and never brokers NEBTYPE_CONTACTNOTIFICATIONMETHOD_END (605), and the worker stores only 605. The openITCOCKPIT Docker images distribute notifications by default.

Change

A new option, off by default, in the configuration pattern of this repository:

YAML	store_notification_start
environment	STATUSENGINE_STORE_NOTIFICATION_START
flag	-store-notification-start

With it on, newContactNotificationMethodHandler stores 604 instead of 605:

• end_time is set to start_time, since the end is not known. The column is NOT NULL without a sub-second part, so 0 would read as 1970.
• This happens before the events are published on the WebSocket, so the stream and the database show the same value.
• The END event is dropped, so where it does arrive nothing is stored twice.

NewRouter takes the option as a new last parameter, as statusMaxAge and mysqlBatchSize were added. config.example.yaml documents the key.

It is the same option as statusengine/worker#42, keeping both workers alike, in the spirit of "Use ev.StartTime ... as this is what the PHP worker used as well".

Tests

• TestContactNotificationMethodHandlerStoresStartEventWhenAsked (new): with the option on, 604 is stored with end_time == start_time and the contact of the START event, and a following 605 is dropped.
• TestContactNotificationMethodHandlerDiscardsNonEndType passes unchanged, so the default behaves as before.
• go vet and gofmt are clean. Six tests fail, all for want of a Gearman or RabbitMQ broker on localhost; the same six fail on main.

---

Note: this change was prepared with AI assistance (Claude Code). The cause was traced in the Naemon, mod_gearman and Statusengine sources, and the fix was measured in a running openITCOCKPIT Docker stack.