feat: support chained sessions (nextSession) on ExtendedIrmaRequest

[dobby-coder]

Closes #9.

Since irmago v0.10.0 a requestor request can declare a nextSession block pointing at a follow-up requestor URL; the server links the two sessions so the second runs immediately after the first succeeds. See chained-sessions docs. This was wire-compatible already, but the typed builders didn't expose it.

Field name confirmation

Verified against the irmago RequestorRequest/RequestorBaseRequest Go struct at v0.19.2 requests.go:

type RequestorBaseRequest struct {
    ...
    NextSession *NextSessionData `json:"nextSession,omitempty"`
}
type NextSessionData struct {
    URL string `json:"url"`
}

So the JSON field is nextSession and the only sub-field is url. The authmethod/key sub-fields floated in the issue do not exist on the upstream struct, so they are intentionally omitted to stay wire-faithful.

Changes

• Add NextSessionData { url: String } (serialized as { "url": ... }) with a NextSessionData::new(url) constructor, mirroring irmago.
• Add next_session: Option<NextSessionData> to ExtendedIrmaRequest, serialized as nextSession and omitted when None (skip_serializing_if = "Option::is_none") — same pattern as skipExpiryCheck in feat: support skipExpiryCheck on disclosure requests #16.
• Add ExtendedIrmaRequest::new(request) and a chainable next_session(url) builder method; export NextSessionData from the crate root.
• README: document chained sessions and note the recommended minimum irmago server version v0.19.0 (GHSA-pv8v-c99h-c5q4 tightens next-session permission handling).
• Add test_next_session covering omission when unset, serialization as nextSession, and JSON roundtrip.

Verification

• cargo fmt --all -- --check — clean
• cargo test — all tests pass (incl. the new test_next_session)
• cargo clippy --all-targets — clean

References

• irmago v0.10.0 release
• Chained sessions documentation
• GHSA-pv8v-c99h-c5q4

🤖 Generated with Claude Code

[dobby-coder]

✅ Verdict: approve — posted as COMMENT only because GitHub blocks self-approval on a bot-authored PR (dobby-coder[bot] is both author and reviewer); treat this as a clean sign-off, not a withheld review. Merge is gated by @rubenhensen's maintainer review.

Rule-compliance + code review complete, no blocking findings:

• Field name & shape verified against irmago v0.19.2 requests.go: serialized as nextSession with a sole url sub-field; authmethod/key are correctly omitted (server-side only).
• Builder + field added on ExtendedIrmaRequest (.next_session(url)), Option, skip_serializing_if so it's omitted when unset — mirrors the skipExpiryCheck pattern from #16.
• Tests: test_next_session covers omitted, set, and serde round-trip; full suite (11 unit incl. new test + 5 integration) passes, clippy/fmt clean.
• README: documents chained sessions and the ≥ v0.19.0 irmago server recommendation (GHSA-pv8v-c99h-c5q4).
• Delivers exactly what #9 requested.

Per-rule Haiku checks flagged fmt/test/readme/draft items; all reconciled as false positives or out-of-scope on review (rustfmt-correct imports, no in-crate validation to reject-test, PostGuard README-template restructure is pre-existing & out of scope for this feature PR, draft state is correct mid-pipeline).