[19.0][IMP] queue_job: support Odoo.sh

[YoussefEgla]

This PR proposes an Odoo.sh-oriented adjustment to queue_job so the runner
can still start and call back into Odoo in deployments where the traditional
server-wide assumptions do not hold.

Context

While validating queue_job on Odoo.sh, I ran into two practical limitations
in the current implementation:

• the runner is normally started from the server-wide / prefork path, but on
  Odoo.sh queue_job is not always loaded as a server-wide module
• the historical callback defaults (localhost, --http-interface,
  --http-port) are not a safe default for Odoo.sh workers, where the stable
  externally reachable target is usually the canonical Odoo.sh hostname for the
  database and stage

That combination means jobs can remain enqueued even though the addon is
installed and the queue is otherwise configured correctly.

What this PR does

• start the runner lazily from the HTTP process when we are on Odoo.sh and
  queue_job is not loaded in server_wide_modules
• derive the default callback target from Odoo.sh metadata when no explicit
  host is configured
• use https://<db_name>.dev.odoo.com for non-production stages and
  https://<db_name>.odoo.com for production
• keep explicit ODOO_QUEUE_JOB_SCHEME, ODOO_QUEUE_JOB_HOST, and
  ODOO_QUEUE_JOB_PORT overrides as the highest-priority behavior so custom
  domains or proxies can still be configured manually
• keep the existing /queue_job/runjob?db=... database resolution path working
  so the lazy-started runner can still target the correct database
• add tests around the new target selection and lazy-start behavior
• update the docs to describe both the new default behavior and the operational
  requirement around hostname reachability

How the limitations were handled

1. Runner bootstrap on Odoo.sh

The first limitation was that the runner was coupled to the usual server-wide
startup path. This branch handles that by adding a lazy bootstrap path:

• queue_job/jobrunner/__init__.py
  • adds _should_start_runner_thread_lazily(...)
  • adds maybe_start_runner_thread(...)
• queue_job/post_load.py
  • calls maybe_start_runner_thread(...) from Request._serve_db
  • keeps the db capture monkey patch for /queue_job/runjob

This gives Odoo.sh a way to start the runner from an HTTP worker without
changing the traditional server-wide behavior for deployments that already load
queue_job there.

2. Callback hostname selection

The second limitation was the default callback target. This branch handles that
in queue_job/jobrunner/runner.py by:

• adding _odoo_sh_stage()
• adding _odoo_sh_host(db_name, stage=None)
• adding _jobrunner_target(db_name, scheme=None, host=None, port=None)
• computing the callback target per database instead of assuming
  localhost:8069

The fallback on Odoo.sh is the canonical hostname for the database and stage.
If operators need a different host, explicit env/config overrides still win.

Remaining limitations

This PR intentionally does not try to solve every possible hosting topology.
The main remaining limitations are:

• custom domains are not auto-discovered
• if a deployment requires the runner to call a custom host, operators must set
  ODOO_QUEUE_JOB_HOST explicitly
• the canonical Odoo.sh hostname must remain reachable from the Odoo workers if
  no explicit override is configured
• there is still no per-database custom-domain mapping beyond the single
  host/scheme/port override mechanism already supported by env/config

I think that is the safer tradeoff for now: use a deterministic Odoo.sh default
and keep custom routing as an explicit operator choice rather than guessing
from website domains or web.base.url.

Main files changed

• queue_job/jobrunner/__init__.py
  • lazy-start decision and one-time bootstrap helper
• queue_job/jobrunner/runner.py
  • Odoo.sh target derivation and per-database callback target selection
• queue_job/post_load.py
  • lazy bootstrap from HTTP request handling
• queue_job/tests/test_runner_runner.py
  • regression tests for dev/staging/production target selection
  • explicit override coverage on Odoo.sh
  • lazy-start condition and duplicate-start protection tests
• queue_job/readme/CONFIGURE.md
  • Odoo.sh configuration notes and hostname reachability requirement
• queue_job/README.rst
  • generated README synced with the same operational notes
• queue_job/static/description/index.html
  • generated description synced as well

Validation

• regression tests were added for Odoo.sh dev, staging, and production target
  selection
• explicit override behavior is covered so custom domains remain supported via
  ODOO_QUEUE_JOB_HOST
• lazy runner bootstrap conditions and start-only-once behavior are covered
• documentation was updated to make the remaining operational requirement
  explicit: if no explicit host override is configured, the canonical Odoo.sh
  hostname must remain reachable from the workers

Feedback welcome

I would especially appreciate feedback on two points:

• whether the lazy-start trigger point in Request._serve_db is the right place
  to bootstrap the runner on Odoo.sh
• whether keeping custom-domain support as an explicit override is the right
  boundary for this fix, instead of trying to auto-discover a public host

[OCA-git-bot]

Hi @guewen, @sbidoul,
some modules you are maintaining are being modified, check this out!