4.X: US States with Subsections - MD, KY, RI, IN

[yuzawa-san]

i came up with this independently to #104 which does not have support for the subsection headers per the spec (at least how i understand it). i came up with this before the spec was finalized but it appears to us the semantics i expected, specifically around the encoding of subsections. i had previously conveyed my concern around how it was not possible to encode the core section with subsection id 0 in the fibonacci string since they do not support encoding 0. given that the spec addresses that:

List of subsection ids that are contained in this section. The IDs must be represented in the order the related subsections appear in the string. The Core subsection is required and always included first, so its ID (zero) is not included in the subsection IDs list.

this introduces a new section subclass which automates this type of state schema
there is no longer need to unencodable booleans since the presence was in the header.

[Tejasshack]

PR 109 — US State Sections

1. SubSections handling in doDecode() does not match the specification.
   The spec states that the Core subsection is always present and appears first, but ID 0 must not be included in the SubSections list.

2. Current bug:
   doDecode() adds the Core ID directly to the live subsection field:

   subSections.addInt(0);

   After decoding, getSubSections() therefore contains 0, which is against the spec.

3. This also breaks encode-after-decode.
   doEncode() always writes the header and core first, then iterates over SubSections. Because 0 was inserted during decode, the Core segment is encoded a second time:

   header.core        -> header.core.core
   header.core.<optional> -> header.core.core.<optional>
   

   The Fibonacci encoder does not expose 0 in the header bits, so the header can still appear valid while the encoded segment structure is wrong.

4. Recommended fix:
   Decode the header and Core independently, without inserting 0 into SubSections. Then consume optional subsection segments in their encoded order rather than deriving the string index from 1 + subsectionId.

5. Add round-trip coverage:
   Please add tests for:

   • Default section: encode(decode(s)).equals(s) and getSubSections() does not contain 0.
   • Section with optional subsection: same round-trip assertion and getSubSections() is exactly {1}.

6. Maryland field name does not match the specification.
   The Maryland GPC subsection defines the field name as SubsectionType. The PR currently exposes it as GpcSubSectionType. The bit layout itself is correct (Int(2) followed by Gpc), but the field name must use the exact spelling from the spec.

7. Other state sections:
   Indiana, Kentucky, and Rhode Island correctly do not define a subsection type field; their sensitive-data subsections contain only SensitiveDataProcessing.

Main points: PR 109 has two spec mismatches:

• doDecode() incorrectly adds Core subsection ID 0 to SubSections, causing incorrect encode-after-decode behavior.
• Maryland uses GpcSubSectionType instead of the spec-defined field name SubsectionType.

Specification for reference
https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform

[yuzawa-san]

@Tejasshack i believe i have applied the desired fixes in my most recent commits