C API allows empty ran_function_data but E3AP schema mandates SIZE(1..32768)

[Thecave3]

Description

The C API and the E3AP ASN.1 schema disagree on whether a Service Model's ran_function_data may be empty:

• C API documents the field as optional: ran_function_data "may be NULL" and ran_function_data_len "0 if none" (include/libe3/c_api.h), and ServiceModel::ran_function_data() defaults to {} (include/libe3/sm_interface.hpp).
• E3AP schema declares it mandatory and non-empty: E3-RanFunctionDefinition.ranFunctionData OCTET STRING (SIZE (1..32768)) (messages/asn1/V1/e3ap-1.0.0.asn1).

Advertising an SM whose ran_function_data is empty therefore violates the APER size constraint and aborts the encode of the entire setupResponse — taking down every other registered RAN function with it.

Why this is the real fix (not encoder padding)

PR #29 proposed papering over this by substituting a 1-byte 0x00 placeholder in the ASN.1 encoder. That masks the contradiction rather than resolving it, and makes a decoded {0x00} indistinguishable from genuine 1-byte data.

An SM should never advertise empty ran_function_data in the first place — even the most minimal SM carries at least its name (see examples/simple_agent.cpp and examples/sm_simple/), and ranFunctionList is itself OPTIONAL, so "nothing to advertise" means omitting the entry, never padding it. The mandatory SIZE(1..32768) constraint is correct and should stay.

Proposed resolution

Tighten the contract at the source so an empty value can never reach the encoder, e.g.:

• Reject empty ran_function_data at SM registration (return an error), and/or
• Update the C API contract/docs so ran_function_data is required rather than "may be NULL".

Context

Split out of PR #29 review (the encoder-padding approach there was declined in favor of fixing the contract here).