Add serial transport

[trond-snekvik]

Adds the serial transport layer, as outlined in golioth/architecture#85. This does not include a real transport adapter, but includes three test suites that test the serial device, serial broker and a test that covers both together, each using mock serial adapters and endpoints.

There's some cleanup and some hacking in the kconfig menusystem going into this PR. The intent is to just kinda make serial build on both the gateway and the device without making our menuconfig worse. I'll make a separate PR with some more deliberate restructuring.

[beriberikix]

Found while bringing up the rpmsg transport in #304, an adapter on this serial core (RFC #274), running against the real device endpoints instead of this PR's mocks.

This early return is right in spirit, but CH_FLAG_PENDING was consumed at the top of the function (line 136, test_and_clear_bit) and isn't restored here — so "wait for the next call" never happens. The channel is permanently un-pending and every later frame_get() bails at line 137.

Worth contrasting with sar/sender.c:94, which has the same "no data at this time, will come back later" early return — but the SAR sender doesn't disarm itself on entry, so a transport can just re-drive it. This path both disarms itself and depends on bearer_ready() to re-arm, which the device endpoints never call: src/transport/endpoints/device/uplink.c implements only start/send/end.

It only bites when an endpoint produces data asynchronously — which is exactly the uplink, since pouch encrypts on its work queue a few hundred ms after the broker prompts the channel. Info and device-cert have their data buffered already and never reach this branch, so a session reliably completes the first three verbs and then hangs. From the Linux-side broker in #304:

{"level":"ERROR","msg":"session handler failed",
 "error":"read uplink: channel 4: timed out waiting for transfer"}

Minimal fix is to re-arm before returning:

Suggested change

	if (len == 0 && result == POUCH_MORE_DATA)
	if (len == 0 && result == POUCH_MORE_DATA)
	{
	// Endpoint has no data ready to send, but expects to be called again later.
	// Re-arm so the transport polls us again; nothing else will.
	pouch_serial_ch_ready(ch);
	return 0;
	}

That's necessary but not sufficient by itself — it only helps if the transport re-drives the channel (the rpmsg adapter uses a short timed wait rather than blocking indefinitely on the ready signal). The alternative, and arguably the better design, is for the uplink endpoint to call bearer->ready() when the work queue produces a block: fully event-driven, no polling, and it fixes every transport at once. That touches src/transport/endpoints/, which this PR doesn't own, so I'd defer to you on the direction.

Possibly related: your note on the clear_bit at line 165 being "a bit of a mix up" — same function, same class of flag-lifecycle issue, so there may be a common cleanup here rather than two isolated patches.

[beriberikix]

Context: RFC #274 proposes running Pouch over rpmsg on heterogeneous MPU+MCU SoCs, where an MCU core runs the Pouch device stack and syncs through a gateway on the Linux side. #304 implements that as an adapter on this serial core rather than a new transport — one Pouch Serial frame per rpmsg message, with no changes to the code in this PR.

This PR notes it "does not include a real transport adapter… each using mock serial adapters and endpoints." #304 is that adapter, and bringing it up on hardware (NXP FRDM-IMX95: Zephyr on the Cortex-M7, Linux plus a Go broker on the Cortex-A55s) exercised the core against the real endpoints for the first time. That turned up one defect not yet raised — commented inline at channel.c:185 — and independently confirmed the one @mniestroj already flagged at channel.c:234.

Both are invisible to CI for the same structural reason, which seems worth fixing alongside them. Across all three suites the mocks in tests/pouch/serial/*/src/stub_endpoints.c differ from the real endpoints in exactly the two ways that matter:

1. All 20 mock vtables define .end. The real pouch_device_endpoint_info and device_cert don't, so the unguarded call at channel.c:234 is unreachable in test but fatal on hardware — the first ACK the broker sends closes the info channel and faults the device.
2. All three mocks share one synchronous send — memcpy from a pre-filled buffer, then return (s->tx_offset >= s->tx_len) ? POUCH_NO_MORE_DATA : POUCH_MORE_DATA;. It never returns POUCH_MORE_DATA with *dst_len == 0. The real uplink endpoint hits that combination on every session, because pouch encrypts on its work queue a few hundred ms after the broker prompts the channel — and the branch at channel.c:185 then deadlocks the transfer.

Two mock variants would close the gap without needing hardware: one with .end = NULL, and one that returns POUCH_MORE_DATA with zero bytes for the first N calls before producing data.

With both fixes applied, a full session completes end-to-end against gw.golioth.io — info, server certificate, device certificate, uplink, downlink — and the MCU registers in the Golioth console as its own device alongside the gateway. Device-side trace of the uplink path that previously hung:

[00:00:05.760] <dbg> pouch_serial_ch: handle_ack: ch4: sender start -> 0
[00:00:05.760] <dbg> pouch_serial_ch: ch4: no data yet, re-arming
[00:00:05.760] <dbg> saead_session: session_encrypt_block: Session key: …
[00:00:08.098] <dbg> downlink: pouch_downlink_start: Pouch downlink start

Ten consecutive sessions, zero errors.

[mniestroj]

2 things from my side, otherwise looks good.

[mniestroj]

Awesome work on the design, implementation and refinement!