backlog: isolate per-sequence state to prevent flag corruption across sequences

[joluxer]

Description

Part of the backlog improvement series documented in discussion #24776.

Implementation choices are open to discussion. If you'd prefer a different approach, please comment -- I'll revise.

Problem

Bug -- Concurrent-rule flag clobber:
Rule1: Backlog0 cmd1;cmd2 and Rule2: Backlog cmd3;cmd4 firing together:
all four commands ran timed. The second rule's enqueue reset the global
nodelay flag to false before the first rule's commands were drained.
Per-entry intent was silently discarded.

Root cause:
Behavioral intent (nodelay, no_mqtt_response) was stored as
global state, set at enqueue and consumed at drain. Any intervening
enqueue or command run could overwrite it.

---

Changes

Fix: intent baked in at enqueue time (bit0=nodelay, bit1=no_mqtt_resp):

Each queue entry now carries its behavioral flags as a prefix byte, set at
enqueue from the staged state. Flags travel with the command;
globals no longer affect them at drain-time.

NoDelay remains one-shot: raises the nodelay flag for exactly the next
enqueued command, then reverts to the sequence baseline (Backlog0/2: all
nodelay; Backlog/1/3: timed). This matches the documented one-command scope
and is now structurally guaranteed rather than dependent on drain-loop state.

ExecuteCommandBlock (IF/ENDIF engine) resets staged flags to plain-Backlog
defaults before inserting commands. IF blocks now behave like a fresh Backlog
invocation: timed, MQTT on. Authors who want NoDelay inside an IF block
write it explicitly -- readable and correct.

SetOption166 (default 0) -- separate drain window for external commands:

Previously, external commands (MQTT, Serial, Button) stalled the drain window
via SO34 -- the same timer that governs inter-command spacing within a Backlog
sequence. This conflated two independent concerns.

SO166=0 (default): external commands schedule BACKLOG_EXT_DELAY (100 ms,
configurable via user_config_override.h), separate from SO34. Existing
behavior is preserved for users who do not set SO166. Backlog queue drain stalls
for short time.

SO166=1: BacklogLoop is sole timer owner. External commands do not stall the
backlog queue drain. The inter-command delay within a Backlog sequence (SO34) is
unchanged in either mode.

Backlog::WarnIfNoDelay(cmd_name_P):

Diagnostic hook for command handlers with settling-time requirements or
interlock dependencies making them unsafe at zero inter-command delay. Logs at
ERROR level when called from a NoDelay drain context. Available for any driver
or command handler to opt in. Delay command uses it.

---

Behavior summary

Scenario	Before	After
Rule1: Backlog0 cmd1;cmd2 / Rule2: Backlog cmd3;cmd4 (both fire)	all four: timed (Rule2 clobbers Rule1's nodelay flag)	cmd1+cmd2: no delay, cmd3+cmd4: timed (per-entry, set at enqueue)
Backlog2 cmd1; IF cond; cmd2; ENDIF	cmd2 MQTT-suppressed (inherited drain state)	cmd2 MQTT on (IF block resets to plain Backlog)
Backlog POWER1; NoDelay; POWER2; POWER3	POWER1: timed, POWER2: nodelay, POWER3: queue timed or no delay unknown, not guaranteed, only POWER2 no delay	now structurally guaranteed
Delay inside Backlog0	silent no-op	silent no-op + ERROR log
External MQTT command during drain	drain window: SO34 (200 ms default)	drain window: BACKLOG_EXT_DELAY (100 ms)
Backlog0 cmd1; cmd2	both: no delay	both: no delay (unchanged) - now structurally guaranteed

Default Backlog / Backlog1 behavior: no change.

---

Memory impact (measured, this PR only)

Ref: pr/backlog-encapsulation tip

Target	Flash	RAM	IRAM
tasmota32	+212 B	-8	0
tasmota-4M	+468 B	0	0

RAM −8 B on tasmota32: per-entry flags replace three drain-loop globals.
Flash cost is the expanded queue entry and IF-block reset logic.

---

Requires pr/backlog-encapsulation: staged flags and queue state must be
inaccessible from .ino scope for the per-entry guarantee to hold.

Build-tested on ESP8266 (tasmota-4M) and ESP32 (tasmota32). Target-tested on ESP32: completed.

Checklist:

• The pull request is done against the latest development branch
• Only relevant files were touched
• Only one feature/fix was added per PR and the code change compiles without warnings
• The code change is tested and works with Tasmota core ESP8266 V.2.7.8
• The code change is tested and works with Tasmota core ESP32 V.3.3.8 from Platform 2026.05.50
• I accept the CLA.

[s-hadinger]

Please review this:

PR 24880 Review Findings

Blocking issue: NoDelay becomes persistent in rule command blocks

In tasmota/tasmota_xdrv_driver/xdrv_10_rules.ino, ExecuteCommandBlock() now handles NoDelay by calling Backlog::SetNodelay(true) and not enqueueing the literal NoDelay command.

Before this PR, rule command blocks inserted NoDelay into the backlog as a normal queue entry. The old BacklogLoop() consumed it as a one-shot sentinel, applying no-delay only to the next real command.

With this PR, the staged NoDelay flag is never reset in the rule insertion path, so all following commands in the same rule block inherit NoDelay.

Example affected pattern:

IF ... DO NoDelay; Power1 1; Delay 10; Power2 1 ENDIF

Expected behavior:

• Power1 1 runs without the standard backlog delay.
• Delay 10 is honored before Power2 1.

Likely PR behavior:

• Power1 1, Delay 10, and Power2 1 are all inserted with NoDelay.
• Delay 10 becomes ineffective because Backlog::ScheduleDelay() no-ops in a NoDelay context.
• Power2 1 may run immediately.

This is introduced by this PR; it was not present in the previous implementation.

Suggested change

Mirror the one-shot logic already implemented in CmndBacklog() when handling rule IF command blocks:

bool nodelay_oneshot = false;
...
if (0 == strncasecmp_P(blcommand, PSTR(D_CMND_NODELAY), strlen(D_CMND_NODELAY))) {
  Backlog::SetNodelay(true);
  nodelay_oneshot = true;
} else {
  Backlog::InsertCmd(blcommand, insertPosition++);
  if (nodelay_oneshot) {
    Backlog::SetNodelay(false);
    nodelay_oneshot = false;
  }
}

[joluxer]

Thanks for the suggestion, I like the idea. I'll look at it during weekend, when I'm back at my laptop.