fix(proxy): return implementing modules in the system's module order (PPT-2816)

[camreeves]

What

system.implementing(interface) walked the redis hash that maps a system's module names to ids and returned modules in that hash's order. The hash has no defined order and core rewrites it on every system update. On HIO UAT on 24 Sep two overlapping updates of one system left it with the Calendar module ahead of the mailers, and every driver that takes the first Mailer implementer (fourteen of them) sent through Calendar, while the Template Mailer, which took the second, forwarded to itself until core was OOM killed.

DriverModel::ControlSystem now carries the system's modules list, which core already includes in the system payload, and implementing sorts its results by position in that list. Modules not on the list follow in name and index order. all(name) is sorted by index for the same reason. The first result is now the module an administrator listed first on the system, whatever order the hash is in.

For a remote system config is fetched once per proxy, the same request system.name and friends already make.

Testing

• New case in spec/drivers_proxy_spec.cr: the hash is written in one order, the system lists another, and implementing follows the system.
• Full suite: 116 examples, 0 failures, 1 pending, against a local redis.

Related

• PlaceOS/drivers #635: the Template Mailer never forwards to itself.
• PlaceOS/core: mapping writes for one system are serialised.

PPT-2816