Changes

systemd: run db-upgrade script in ExecStartPre

We have seen in CI jobs that calling the DB upgrade script from
debian/postinst does not work reliably.

When doing a fresh install of osmo-hlr, it usually works as expected:

  Setting up osmo-hlr (1.9.2) ...
  osmo-hlr-post-upgrade: nothing to do (no existing database)

But sometimes:

  Setting up osmo-hlr (1.9.2) ...
  osmo-hlr-post-upgrade: database upgrade is required
  osmo-hlr-post-upgrade: stopping osmo-hlr service
  osmo-hlr-post-upgrade: creating backup: /var/lib/osmocom/hlr.db.20260706135658.bak
  osmo-hlr-post-upgrade: performing database upgrade
  <0001> db.c:600 using database: /var/lib/osmocom/hlr.db
  <0001> db.c:103 (283) recovered 4 frames from WAL file /var/lib/osmocom/hlr.db-wal
  <0001> db.c:679 Database '/var/lib/osmocom/hlr.db' has HLR DB schema version 0
  <0001> db.c:103 (1) duplicate column name: last_lu_seen in "ALTER TABLE subscriber ADD COLUMN last_lu_seen TIMESTAMP default NULL"
  <0001> db.c:248 Unable to prepare SQL statement 'ALTER TABLE subscriber ADD COLUMN last_lu_seen TIMESTAMP default NULL'
  <0001> db.c:318 Unable to update HLR database schema to version 1
  <0001> db.c:685 Failed to upgrade HLR DB schema to version 1: (rc=1) duplicate column name: last_lu_seen
  <0000> hlr_db_tool.c:509 Error opening database

It seems that osmo-hlr can get started before the osmo-hlr-post-upgrade
script runs, then starts to create the database with the current schema,
and gets stopped before it is done, leading to the failure above.

Rename the script to osmo-hlr-db-upgrade.sh, remove logic for stopping
and starting the service and let systemd call it in ExecStartPre. That
way we are sure that it runs *before* osmo-hlr starts up.

Related: SYS#8125
Change-Id: If13f4c8b49397e6630956e92a7825843c7d55ebd