Experiment with ifdef-guarded changes

[leighmcculloch]

What

Experiment with ifdef-guarded changes.

Why

For:

• https://github.com/stellar/pod-fsr/issues/13

[Copilot]

Pull request overview

This PR experiments with introducing an optional SCV_SPARSE_MAP variant into the Soroban SCVal XDR by conditionally compiling enum/union members behind a SPARSE_MAP preprocessor define.

Changes:

• Adds SCV_SPARSE_MAP to SCValType when SPARSE_MAP is defined.
• Adds a corresponding SCV_SPARSE_MAP arm to the SCVal union when SPARSE_MAP is defined.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Using #ifdef SPARSE_MAP inside the XDR enum makes the numeric type space dependent on compile-time flags. This can lead to incompatible serialized data between components built with different defines (e.g., one side knows SCV_SPARSE_MAP and the other doesn’t). Prefer keeping the XDR schema deterministic (e.g., define the new enum value unconditionally or introduce a separate, versioned XDR type) rather than CPP-guarding enum members.

[Copilot]

The SCV_SPARSE_MAP union arm is also CPP-guarded. If one producer is built with SPARSE_MAP and emits type 22, a consumer built without it will fail to decode the SCVal union. Consider keeping the union arm present (even if unused) to maintain wire compatibility across builds, or move this experiment behind protocol-versioned/explicit feature negotiation instead of preprocessor guards in XDR.

[Copilot]

Field name sparseMap uses camelCase, while other SCVal union arms use snake_case (e.g., nonce_key) or short identifiers (vec, map). Rename to a consistent style (e.g., sparse_map) to match the surrounding XDR conventions and generated bindings.

Suggested change

	SCMap *sparseMap;
	SCMap *sparse_map;