feat(orders): add support for Hubble ordering system

[Yoronex]

Description

This PR adds a new module that implements the ordering system for Hubble. It's goal is to receive order numbers and show them for a certain amount of time on all screen clients. New orders are sent to Aurora using an HTTP endpoint. Then, every time an order is added or manually removed, Aurora sends a SocketIO message to all screen clients with the complete list of all order numbers. Each order number also includes the creation time and after how many seconds the order should be hidden. Note that Aurora Core does not send a message when an order number is expired: the screen clients should hide these themselves after their expiry (to save network resources and server side complexity).

The list of orders is not persistent: it is stored in memory.

Related issues/external references

Types of changes

• New feature (non-breaking change which adds functionality)

[Yoronex]

@PimVanLeeuwen and @SuperVK please let me know whether the endpoints described in the OpenAPI spec are something you can work with!

[PimVanLeeuwen]

I have asked Christiaan from Hubble who will implement the API on the register side and he will take a look at this PR for it.

[christiaangoossens]

I have asked Christiaan from Hubble who will implement the API on the register side and he will take a look at this PR for it.

I will still do that, it's just stalled on the todo list at the moment due to starting a new job.

[christiaangoossens]

The documentation you need is now available at https://docs.starcommunity.app/docs/webhooks/hooks/food-order-completed. For authentication, I settled on using the same system for all webhooks that we send: RSA-SHA256 (https://docs.starcommunity.app/docs/webhooks/signatures).

For Aurora this means:

• Aurora can either be hosted within the network or on the internet
• There is no explicit need to firewall the webhook endpoint
• We do not need to configure shared keys / JWT secrets / keep environment variables etc
• Aurora verifies the signature on any webhook it processes and rejects it (with logging) if the signature fails
• All webhooks sent in Hubble will use the production key available at https://api.starcommunity.app/.well-known/webhooks.key (after this is in production). You should cache that key, but not indefinitely, to allow for key rollover (which will only happen if it's leaked/compromised).

You can test your implementation without any webhooks by using the example webhook body/signature header against your implementation.

@Yoronex Is this enough to finish the implementation? I tested the example code on the docs as well and it all verified for me.