daemon: parse incrementally in dlt_daemon_control_set_trace_status_v2 (V2 control-handler family, ref #866)

[SoundMatt]

Problem

dlt_daemon_control_set_trace_status_v2 was the most severe of the
V2 control-handler bugs documented in #866 — it cast msg->databuffer
directly to DltServiceSetLogLevelV2 *:

req = (DltServiceSetLogLevelV2 *)(msg->databuffer);
...
dlt_set_id_v2(apid, req->apid, req->apidlen);

DltServiceSetLogLevelV2 contains char *apid and char *ctid
pointer fields. Under the direct cast, those fields were filled with
8 bytes of network input each (interpreted as pointer values), then
dereferenced by dlt_set_id_v2. Arbitrary memory read from network
input. The daemon either crashed (most pointers invalid) or read
from an attacker-chosen address.

Plus two compounding bugs:

• Same NULL-deref pattern as dlt_daemon_control_set_log_level_v2 never assigns req.apid/req.ctid; silently fails or crashes the daemon #863 / daemon: parse apid/ctid in dlt_daemon_control_set_log_level_v2 #864 — locals apid / ctid
  declared NULL, never reassigned, dereferenced at
  apid[apid_length - 1] etc.
• (int8_t) cast on uint8_t apidlen / ctidlen produced a negative
  value for lengths > 127, leading to a negative array-index
  underflow at the same dereference points.

Reachable from any client able to send control messages (dispatched
from dlt_daemon_handle_control_messages_v2, line 1278).

Fix

Replace the struct cast with incremental parsing, mirroring the
surgical approach already taken for set_log_level_v2 in #864:

• Read each fixed-size field via memcpy into a local primitive.
• Point apid / ctid into msg->databuffer only when their
  corresponding length is non-zero.
• Add bounds checks after each length is parsed, mirroring daemon: fix out-of-bounds read in dlt_daemon_control_set_log_level_v2 #862.
• Use unsigned widths throughout this function — drop the
  (int8_t) casts on apid_length / ctid_length.

Notes

• Downstream helpers (dlt_daemon_find_multiple_context_and_send_trace_status_v2,
  dlt_daemon_send_trace_status_v2) still take int8_t length
  parameters. That narrowing remains a separate latent issue — a
  caller passing apidlen > 127 (legal in the wire protocol's
  uint8_t range) still gets a sign-flipped length passed
  downstream. Called out in a code comment; out of scope for this
  PR. Will follow up if maintainers want.
• Same hand-written control flow as the original (wildcard / "field
  only" / "exact match" branches) — only the parsing and the local
  variable widths changed.
• Tested by reading the diff and the V2 protocol layout against the
  size constant DLT_SERVICE_SET_LOG_LEVEL_FIXED_SIZE_V2 = 11. Have
  not added a regression test.

Related: #866 (META — V2 control-handler systemic problem).
Mirrors: #864 (same surgical approach for set_log_level_v2).

[SoundMatt]

Proactively aligned this with the rest of the V2 control-handler family (#864/#868/#861): apid/ctid are now copied into local char[DLT_V2_ID_SIZE] buffers through the shared dlt_set_id_v2() helper instead of aliasing the receive buffer, so id initialisation stays inside the helper API. The incremental parse and the two bounds checks are unchanged. Also added Signed-off-by.