Read a body from message_payload and accept data_sm (#84)

* Regression tests for a body in message_payload and for data_sm

* Read a body from message_payload and accept data_sm

* Assert the fixed message_payload and data_sm behaviour against Jasmin

* Record the message_payload and data_sm fixes in the Jasmin findings

* Read an inbound data_sm as the direction it travelled, and export messageOctets

* Refuse a segment with the code its stand-in command defines

* Name the stand-in the refusal status is read from

interop-tests/findings/03-jasmin.md

@@ -99,6 +99,13 @@ send it over the connector's session, and inspect the `sms` event at a client bo
 **Severity.** Medium: silent data loss, not a wire error - the message is fully present on the wire
 and Jasmin forwards it faithfully; only this library's read of it is incomplete.
 
+**Fixed** in [#84](https://github.com/larvit/larvitsmpp/pull/84): the body is read from
+`message_payload` where `short_message` carries none. The relay is confirmed on the wire - the
+capture's one `sm_length` 0 `deliver_sm` is Jasmin's own, out of `smpps` to our client, carrying the
+`0x0424` TLV intact. The reproducer's own fixture was wrong as well as the library: it built the TLV
+as Latin-1 while the PDU declared `data_coding` 0, so `_` (GSM 03.38 0x11, Latin-1 0x5F) came back
+as `§` even once the body was read. It now encodes the payload the way the PDU says it is written.
+
 ### `sar_*`/UDH segmentation from an upstream SMSC reassembles fine (target 3, MO direction) - not reproduced as a defect here
 
 C8's SAR and UDH MO pushes both reassembled into one whole `sms` at our real client. This does not
@@ -121,6 +128,12 @@ Our client's `incomingPduObj` sees it arrive; no `dlr` event ever fires. The rec
 **Severity.** Medium: a real, documented Jasmin configuration (`dlr_pdu = data_sm`) that a receipt
 depends on silently drops delivery reports, with no error surfaced to the application either.
 
+**Fixed** in [#84](https://github.com/larvit/larvitsmpp/pull/84): `data_sm` is classified and
+answered exactly as `deliver_sm` is, and the receipt reaches `dlr` naming the id the `submit_sm_resp`
+carried, `DELIVERED`. The wire histogram still shows no `data_sm`: `capture` runs
+`network_mode: service:jasmin`, so it only ever sees the main instance's namespace, never
+`jasmin-datasm`'s.
+
 ### A multi-part MT send deadlocks against Jasmin's serialized per-connector relay - a library/peer interaction, not a wire defect
 
 **What happened.** A 2-, 3-, 10-segment GSM or UCS-2 message sent through Jasmin's `smpps` (our real
@@ -215,6 +228,11 @@ arrives, with `<base>-<n>` off an id the group is opened with. All four multi-se
 - Whether the deadlock above is specific to a message requesting a receipt (`registered_delivery`
   set) or would also occur for a plain multi-segment send with no `dlr` - not isolated separately,
   since every `C3+C7` case here requests one.
+- Whether a real peer accepts a `data_sm_resp` carrying a `message_id`. SMPP 3.4 4.7.2 defines the
+  field, unlike `deliver_sm_resp`'s, and this library fills it when a `data_sm` carried a message -
+  but Jasmin only ever sends one as a receipt, which is answered with the field empty, so the filled
+  case has met no peer. Jasmin FINing over a `deliver_sm_resp` that carried one is the nearest
+  precedent there is.
 - Whether Jasmin, given an *upstream* connector that itself defaults to SAR (rather than our
   library's own UDH), would relay an MT message using SAR instead of preserving our UDH bytes - the
   120s-timeout deadlock always intervened before a second segment could be observed on the wire in