NethVoice: simplify database initialization and service startup #8247

Database preparation and service restarts are spread across configure, update and FreePBX initialization. Consolidate shared database preparation in the MariaDB image, prepare allocated ports before FreePBX starts, and use one planned service restart. Build-time FreePBX patches preserve prepared bindings, including secure WebSocket settings.

Implementation: nethesis/ns8-nethvoice#1063
Parent: #7570

Test cases

Use the PR testing image published by CI. Use a disposable instance or isolated fixtures for permission, catalog and generated-file changes; retain protected configuration exports and verify no active calls before disruptive operations.

• Fresh installation: Install and configure a fresh instance. Verify the database already contains its allocated SIP UDP/TCP/TLS, IAX, manager, RTP and WebSocket ports before FreePBX module installation. After initialization, verify the corresponding live listeners, including secure WebSocket, and confirm that initialization did not restart Asterisk a second time.
• Existing-instance update: Update a configured instance with a queued legacy SQL fixture to the PR image. Verify the SQL import and database/generated-configuration preparation finish before the planned restart, MariaDB starts before FreePBX, configuration/integrations are preserved, and Asterisk remains stable through initialization. Confirm the eight removed compatibility scripts are absent after image extraction.
• Reconfiguration preserves administrator changes: On an unassigned test profile with the Phonebook macro and advanced phonebook access (ad_phonebook), withhold phonebook_level_0 and phonebook_level_2; change a bundled provider description. Save the existing instance settings again. Verify those changes remain, allocated bindings have no duplicate rows, and MariaDB/FreePBX each restart once after preparation.
• Reload contention: Hold FreePBX's reload lock briefly while invoking live configuration preparation. Verify the helper retries the lock rejection and succeeds after release, without restarting or reloading the running Asterisk process.
• Offline binding preparation: Prepare an isolated saved-configuration volume with source-instance ports, shared old UDP/TCP ports, a secure WebSocket tlsbindaddr, and blank section separators. Run the offline preparation path. Verify every generated binding uses its destination port, line/section boundaries remain intact, and custom files are unchanged.
• Invalid-port rejection: Invoke the CI database initializer with an out-of-range port and with fullwidth digits under a UTF-8 locale. Verify it exits with validation failure before database changes and leaves the running services untouched.

Test results

Tested target: ghcr.io/nethesis/nethvoice:pr-1063.1179-1.e4b5a55 from CI build 39250875618, commit df9f4b06. Tests run on a dedicated NS8 test node; the upgrade baseline is CI image pr-1063.1177-1.08006dd.

• Fresh installation: passed. Fresh database bindings were checked before FreePBX module installation; live listeners, secure WebSocket and stable Asterisk initialization passed.

• Existing-instance update: passed. Queued SQL was consumed before catalog refresh; permission backfills ran. Preparation preceded the single MariaDB/FreePBX restart, settings/integrations were preserved, all listeners passed and all eight removed scripts were absent.

• Reconfiguration preserves administrator changes: passed. Withheld profile permissions and the edited provider description remained unchanged. Binding rows were unique; MariaDB and FreePBX each started once after preparation.

• Reload contention: passed. The real reload lock produced contention; preparation retried and succeeded after release. Asterisk process and reload counters confirmed no restart/reload.

• Offline binding preparation: passed. The CI image rewrote all generated bindings correctly, including shared old UDP/TCP ports and IPv4/IPv6 secure WebSocket bindings. Complete-file comparisons preserved blank lines and custom content.

• Invalid-port rejection: passed. Both out-of-range and fullwidth port values were rejected with exit 2. Database bindings and running MariaDB/Asterisk containers were unchanged.

All disposable instances, profiles, pending SQL and temporary volumes created for these tests were removed. The pre-existing instance was left intact. Protected exports and verification evidence were retained on the test node.