Accept apt release-info changes so upgrades cannot fail silently

[antobinary]

Fixes #851

The bug

apt refuses to use a repository whose Release Origin or Label changed until
the change is accepted once, and a rejected fetch leaves the previously cached
package lists in place.

bbb-install.sh calls bare apt-get update in five places and has no set -e,
so that rejection is ignored. The dist-upgrade that follows finds nothing new,
need_pkg sees everything already installed, and the script restarts the server
and reports success — while leaving it on its old version.

This is not hypothetical. noble-400 gained Origin: and Label: on
2026-09-04 (they had been empty, inherited from a verbatim Release copy). Every
4.0 server whose apt cache predates that is blocked, and re-running the
installer cannot clear it. That is how a server asked for 4.0.0-rc.3 and stayed
on rc.2 with a clean-looking run.

The change

Route the five apt-get update call sites through a helper that passes
--allow-releaseinfo-change:

apt_update() {
  # --allow-releaseinfo-change: without it a changed Release Origin/Label makes
  # apt keep the stale lists, so the dist-upgrade below silently upgrades nothing.
  if ! apt-get update --allow-releaseinfo-change "$@"; then
    say "WARNING: apt-get update reported errors; package lists may be stale" >&2
  fi
}

Call sites: main (324), need_pkg (673), install_docker (1513),
install_ssl (1544), install_coturn (1875). All five are inside functions and
main "$@" runs at the bottom of the file, so the helper is defined before any
call executes.

Because the installer is fetched fresh from GitHub on every run, this also
unsticks servers that are already blocked: their next normal upgrade accepts the
pending change and proceeds, with no per-server intervention and no release-note
instructions.

Verification

Against apt 2.8.3 with a local HTTP repo. Starting from a cache holding the old
empty-Origin Release with the server at rc.2, then publishing rc.4 with
Origin/Label set:

  server is at rc.2, cache from before Sep 4:
      cached: Version: 2:4.0.0~rc.2
  --- TODAY: bare 'apt-get update' ---
      blocking errors: 2
      cached: Version: 2:4.0.0~rc.2     <- stuck
  --- PATCHED: apt_update() ---
      cached: Version: 2:4.0.0~rc.4     <- unstuck

Per-field behaviour, tested one field at a time: Origin and Label changes
block (exit 100); a Suite change is accepted silently. Acceptance is
one-time — plain apt-get update is clean afterwards, including across a later
Suite change.

bash -n clean.

Note on the warning vs aborting

The helper warns rather than aborting. apt-get update returns non-zero for any
configured repository, so making it fatal would turn a transient Ubuntu mirror
hiccup into a failed install — a worse regression than the one being fixed. The
silent-success path is closed either way: the known cause is now handled, and
anything else is reported.

Other branches

If adopted, should be ported to branch v4.1.x-release too. v3.0.x-release and prior don't need this change as I only set the Origin and Label on 4.0.

[GhaziTriki]

It looks good to me, it worked upgrading to 4.0-rc3.