Resolve "MAS-DT define instruction set and instructions"

Closes #62 (closed)

examples/mas-dt/instruction_set.json

+{
+  "header": {
+    "message_ID": "b427003c-0000-11aa-a1eb-bvcdfghjgfdd",
+    "timestamp": "2024-09-03T00:00:00Z",
+    "version": 1,
+    "source": "ori",
+    "destination": "internal.noc.slocum.unit_111.to_platform.instruction_set",
+    "delivery_type": "publish",
+    "encoded": false
+  },
+  "payload": {

[Owain Jones]

Ah! I don't know how I missed this before, but there's no platform_ID in the payload like there is with mission plans! In testing I was adding my own platform_ID to the messages without thinking of the fact it's not there.......

It's implied from the destination topic, slocum.unit_111 -- so I can work around that in sfmc-adapter (extract from destination when platform_ID is missing) for now but I think these messages probably do need platform_ID

[Dan Jones]

Oh crap yeah. That's not right is it? I was hoping that they could just send the instruction set payload from the planning_configuration unaltered which kinda makes sense for MAS-DT/MOGli where there is only one glider but doesn't work in the general case.

[Dan Jones]

We could make the instruction_set a sub-schema within something like a platform_instruction_set message so they build the message payload with the platform_ID and then just attach the pre-defined instruction_set?

[Owain Jones]

So:

{
 "payload": {
  "message_type": "platform_instruction_set",
  "platform_ID": "unit_111",
  "instruction_set": {...}
 }
}

?

That'd work. imo I think it's simpler to just add platform_ID to the instruction sets themselves, it's not onerous to add a field to a bit of JSON being sent. Plus they still need to build up the destination string when publishing the message, right? (So already doing the work of knowing what glider to send it to etc)

Up to you. If you stick to the structure above I can quickly add in some code on sfmc-adapter side to handle platform_instruction_set. Alternatively, if adding platform_ID to instruction_set as-is, I've already updated it to handle that, and falling back to getting platform ID from the destination topic when that doesn't exist. So it'll work as-is as long as they publish to the right channel.

[Dan Jones]

I think the reason I was thinking about the sub-schema is that we can't specify the platform_ID in the version we send in the planning_configuration.instructions so if it's the same thing then the platform_ID can't be required. Whereas if I make it a section within the message payload then the platform_ID in the message can be a required field.