[BUG] [regression] jobs scheduled based on the startup time of the minion do not run at minion startup by default

[bugfood]

Description
The documentation says:
https://docs.saltproject.io/salt/user-guide/en/latest/topics/scheduler.html

By default, any job scheduled based on the startup time of the minion will run the scheduled job when the minion starts up.

This is not currently true.

Setup
/etc/salt/minion.d/module_sync.conf:

schedule:
  sync_modules:
    function: saltutil.sync_modules
    minutes: 30
  refresh_modules:
    function: saltutil.refresh_modules
    minutes: 30

/etc/salt/minion.d/minion.conf:

# See /etc/salt/minion.conf for descriptions.

master:
- dsalt01
- dsalt02


random_master: True
id: <redacted>
random_reauth_delay: 10
ping_interval: 10
loop_interval: 10
grains_refresh_every: 0
hash_type: sha256
log_file: /var/log/salt/minion
key_logfile: /var/log/salt/key
log_level_logfile: info

Please be as specific as possible and give set-up details.

• on-prem machine
• VM (KVM, AlmaLinux 8.5)
• VM running on a cloud service, please be explicit and add details
• container (Kubernetes, Docker, containerd, etc. please specify)
• or a combination, please be explicit
• jails if it is FreeBSD

Steps to Reproduce the behavior

1. Install salt 3004.1 (probably not critical--any recent version should do it)
2. Set up config files as pasted above.
3. Restart the minion service.
4. Observe /var/log/salt/minion; note that there are no log entries for sync_modules or refresh_modules jobs.
5. Modify /etc/salt/minion.d/module_sync.conf to add run_on_start: True to either job or both jobs.
6. Restart the minion service.
7. Observe /var/log/salt/minion; note that there are now log entries for whichever job(s) were explicitly set to run_on_start.

Expected behavior
As per the documentation (and previous salt-minion behavior), run_on_start should default to True for jobs run at intervals (inherently "based on the startup time of the minion").

Screenshots
If applicable, add screenshots to help explain your problem.

Versions Report

salt --versions-report

(Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)

Salt Version:
          Salt: 3004.1
 
Dependency Versions:
          cffi: Not Installed
      cherrypy: Not Installed
      dateutil: 2.6.1
     docker-py: Not Installed
         gitdb: Not Installed
     gitpython: Not Installed
        Jinja2: 2.10.1
       libgit2: Not Installed
      M2Crypto: 0.35.2
          Mako: Not Installed
       msgpack: 0.6.2
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     pycparser: Not Installed
      pycrypto: Not Installed
  pycryptodome: Not Installed
        pygit2: Not Installed
        Python: 3.6.8 (default, Nov 17 2021, 16:10:06)
  python-gnupg: Not Installed
        PyYAML: 3.12
         PyZMQ: 19.0.0
         smmap: Not Installed
       timelib: Not Installed
       Tornado: 4.5.3
           ZMQ: 4.3.4
 
System Versions:
          dist: almalinux 8.5 Arctic Sphynx
        locale: UTF-8
       machine: x86_64
       release: 4.18.0-348.20.1.el8_5.x86_64
        system: Linux
       version: AlmaLinux 8.5 Arctic Sphynx

Additional context
This was broken by 391424c and entrenched into the test suite by c68f6be. I will provide a PR.

[OrangeDog]

The new behaviour seems better to me - less complex than having defaults change based on other arguments.
Perhaps the documentation should just be changed (and release notes updated).

[bugfood]

@OrangeDog I can see your point. Speaking as a user, though, encountering this as a regression was quite confusing. It also seems natural to me that something that executes at intervals should execute at time 0 as well, especially for a job that has never been run (e.g. a new minion on a new server).

Please do let me know if you want to retain the current behavior, though, so that I can discontinue work on the PR.

[OrangeDog]

The decision isn't up to me. Though either way there needs to be better tests there. The current ones will pass with almost any behaviour.

Speaking as a user, I always set run_on_start when I want it to run on start, and had assumed the default was False if I didn't.

[garethgreenaway]

The default for schedule jobs that use parameters like seconds, minutes, hours, etc. will initially run when the minion starts up by default. I tested this with the latest 3006 release and saw the jobs run when the minion first started. Can you test again with the latest release? Thanks!