Add faster startup polling before switching to steady-state interval

[ejboy]

Goal

Improve StatLite's first-run and demo experience without permanently increasing polling frequency, database growth, or target load.

New users often start StatLite, open the dashboard, generate a little traffic, and expect to see the charts react quickly. A 60-second default interval is lightweight for long-running use, but can make the initial experience feel stale.

Use a faster polling cadence for a short startup period, then automatically switch to a slower steady-state cadence.

Proposed behavior

When polling.interval is not explicitly configured:

• poll immediately at startup;
• poll every 30 seconds for the first hour;
• after one hour, switch to 60-second polling.

Example behavior:

Startup
  immediate poll
  30s
  30s
  ...
  first hour

Steady state
  60s
  60s
  ...

Explicit configuration must remain fixed

If the user explicitly sets:

polling:
  interval: "30s"

StatLite must continue polling every 30 seconds indefinitely.

Do not silently reinterpret an explicitly configured interval as a startup interval.

The adaptive startup behavior should apply only when the polling interval is omitted and StatLite is using its default behavior.

Rationale

The startup interval is primarily an onboarding and demo optimization.

A first-time user should be able to:

1. start StatLite;
2. open the dashboard;
3. generate traffic or change application behavior;
4. see those changes reflected reasonably quickly.

Thirty-second polling provides that feedback without making the initial workload excessively aggressive.

After the initial discovery period, 60-second polling is sufficient for StatLite's lightweight production-monitoring use case and reduces:

• HTTP requests to monitored applications;
• SQLite writes;
• database growth;
• CPU and I/O overhead.

Configuration semantics

Update configuration handling so that the implementation can distinguish between:

• polling.interval omitted;
• polling.interval explicitly configured.

Do not infer this only from the resulting duration value.

The effective behavior should be:

Configuration	Startup	Steady state
interval omitted	30s	60s
interval: "15s"	15s	15s
interval: "30s"	30s	30s
interval: "60s"	60s	60s

The existing polling timeout behavior should remain unchanged.

Timing

Use the StatLite process/startup lifetime for the startup window.

A StatLite restart begins a new startup polling period. This is acceptable because the purpose is deterministic startup behavior rather than long-term adaptive sampling.

Do not persist startup-period state in SQLite.

Dashboard and storage behavior

No storage schema changes should be necessary.

Poll timestamps remain the source of truth, so stored history may naturally contain:

• denser 30-second samples during the first hour after StatLite starts;
• 60-second samples afterward.

Existing range queries, aggregation, counter-delta handling, and restart detection should continue to work with non-uniform sample spacing.

Verify this explicitly in tests.

Documentation

Update the polling configuration documentation.

Explain that when polling.interval is omitted, StatLite uses:

30s for the first hour, then 60s

Explain that setting polling.interval explicitly disables startup cadence switching and uses that exact interval continuously.

Do not describe this as dynamic or load-based adaptive polling. It is a simple deterministic startup polling policy.

Non-goals

Do not add:

• load-based adaptive polling;
• target-specific automatic intervals;
• polling frequency based on application activity;
• persistent cadence state;
• dashboard controls for polling interval;
• automatic changes to explicitly configured intervals.

Keep the behavior simple and predictable.

Acceptance criteria

• First poll still occurs immediately on startup.
• With polling.interval omitted, polls run approximately every 30 seconds during the first hour.
• After the startup period, the same instance polls approximately every 60 seconds.
• Explicitly configured intervals never change automatically.
• Restarting StatLite starts a new startup polling period.
• Existing polling timeout semantics remain unchanged.
• Existing history/query behavior works correctly across the 30s-to-60s cadence transition.
• Tests cover omitted versus explicitly configured interval behavior.
• Documentation clearly explains the default startup and steady-state cadence.