packaging: restart imsd and imsd-ofonod on upgrade

An upgrade left the old imsd and imsd-ofonod running until they were
next restarted, while a changed bus policy is live the moment apk writes
it: dbus-broker-launch reloads on its own. A policy that relies on a
check inside the daemons would face the old daemons in between.

Mark imsd.service and imsd-ofonod.service needs-restart in post-upgrade
scripts; the systemd trigger restarts them once the transaction is done
(enqueue-marked). A call in progress ends. The same scripts run as
post-install: `apk del` removes a package's files and leaves its daemon
running, so a later `apk add` of the package is this upgrade for that
daemon — and apk runs the post-install script, not post-upgrade, for a
package it adds. GNOME Calls 50.0 dials nothing after imsd-ofonod
restarts under it until it restarts too, so imsd-ofonod's ExecStartPost
restarts the Calls daemon of each user running one — not at the unit's
first start since boot, when a Calls that runs already is left alone.

A daemon older than 0.3.10 kept its bring-up throttle wait in memory
only, so a restart lost it. imsd's post-upgrade records that daemon's
invocation, and imsd-handover.sh, an ExecStartPre after ims-pdn-up.sh,
reads the invocation's journal and, while the fresh-SA throttle's wait
it finds there still runs (`spi-s=0`; the old daemon's other deferrals
are not handed over), writes what is left of it to the holds file when
this start's LOCAL is the address the wait was earned on, or when that
address cannot be read; when LOCAL is another address, only the verdict
that the old registration is gone.

Tested on the dev phone (KPN) in builds of this series; not every path
has run there.

README.md

@@ -149,7 +149,11 @@ On a phone the daemon runs as root on the system bus (policy in
 account `user` access; adjust it if your session account is named
 differently), started by `packaging/imsd.service`
 after `packaging/ims-pdn-up.sh` has brought up the ims PDN through
-ModemManager. The bring-up never lets the ims PDN become the phone's IPv6
+ModemManager. An apk upgrade restarts `imsd` and `imsd-ofonod` once the
+transaction is done (a call in progress ends), as does adding a package
+again over the daemon an `apk del` left running; the restart resumes the
+registration over its existing SAs, or goes on waiting out a hold the
+network had set. The bring-up never lets the ims PDN become the phone's IPv6
 default route: the PDN's router advertisement is not accepted as a default
 router (`accept_ra_defrtr=0` on the netdev; its prefix and MTU still apply)
 and the P-CSCF gets a host route instead, so on IPv4-only wifi the phone's
@@ -227,7 +231,7 @@ Known gaps, all inherited rather than introduced:
   normal dialpad is unaffected — that reaches imsd's own classifier.
 - DTMF is forwarded to imsd, where `SendDtmf` is still a stub (RFC 4733 is not
   implemented yet) — the same limitation Plasma has.
-- **Restart GNOME Calls after restarting `imsd-ofonod` itself.** When the
+- **Restarting `imsd-ofonod` restarts GNOME Calls with it.** When the
   modem's `VoiceCallManager` interface goes away and comes back, Calls 50.0
   adds a new origin but leaves the old origin's `CallAdded` handler connected:
   after one such cycle every call is added twice, after a few the stale handler
@@ -237,7 +241,10 @@ Known gaps, all inherited rather than introduced:
   restarts and registration drops from triggering it, `imsd-ofonod` lists the
   interface permanently: `Online` tracks registration, and `Dial` fails with
   "imsd is not registered" / "imsd is not running" instead. Only `org.ofono`
-  vanishing — this daemon restarting — still cycles the origin.
+  vanishing — this daemon restarting — still cycles the origin, and after
+  that Calls dials nothing until it restarts, so the unit's `ExecStartPost`
+  restarts the Calls daemon of every user running one. Its first start
+  since boot leaves a running Calls alone.
 
 Development, without a phone or root:
 
@@ -311,12 +318,24 @@ refused or throttled fresh attempt); imsd-ofonod refuses a `Dial` then, and
 imsd-dialerd lists no modem. A bring-up the network deferred waits the same
 schedule out with nothing to reconnect over (the resume just found the
 stored SAs unusable), then tries again. The network's holds outlive a
-restart of imsd: they are kept in
+restart of imsd (an upgrade restarts it): they are kept in
 `/run/imsd.holds` for the PDN they were set on, with the schedule's place
 (a restart does not start it over at 21 min), and waited out at the next
 start, before the resume (a refresh's `Retry-After`) or before the fresh
 registration (a fresh attempt's schedule or `Retry-After`, a terminated
-binding's wait); a reboot or another PDN address starts clean.
+binding's wait); a reboot or another PDN address starts clean. An upgrade from a daemon
+older than 0.3.10, which kept its bring-up throttle wait in memory only,
+hands that wait over the same way when this start registers on the address
+it was earned on (the fresh-SA throttle's wait, `spi-s=0`; the old daemon's
+other deferrals, after a 401 it could not use, are not handed over): the
+upgrade records that daemon's invocation, and the next
+start reads its journal lines once the daemon has stopped — a wait that
+ended meanwhile is read as it ended; on another address (the normal hop:
+0.3.9 sat on the kernel's temporary address) only the verdict that the old
+registration is gone is kept and the start registers fresh at once. When
+the old address cannot be read the wait is handed over anyway; when the wait
+cannot be timed, or this start has no `LOCAL`, the journal says it was not
+handed over.
 The journal says which (`…; next: fresh registration in N s`, `registering
 fresh (recovery attempt N)`, `fresh registration deferred/refused/failed:
 …`, `bring-up deferred: …`). One case leaves through a real restart