Add ability for WS client to publish MQTT messages to topics

[ddellacosta]

This should probably have been three separate PRs, especially considering the size, although ~1/3 of the lines added in this PR are auto-generated boilerplate in ui/package-lock.json.

In any case, here are the main chunks of functionality introduced, along with pointers and context for the most important pieces of each:

• The main functionality introduced is as the title describes: this PR provides the ability to publish MQTT messages over a WebSocket connection via the HTTP client. This is exposed through the user interface in a simple text input field and "Publish" button as is seen in the screenshot above. This has been tested manually, and there are integration tests for the backend and frontend pieces of this introduced in this PR as well. Introducing acceptance tests is in the queue.

  • This includes all of the Haskell changes, which introduce a bit of support for starting up HTTP by default, for one: a new "HTTPDefault" Automation that is only run by Service.Daemon, like StateManager. This includes an httpPort value which has been added to the Dhall config, with all the appropriate boilerplate. HTTPDefault starts up the formerly argument-less HTTP automation with the port as is set in the config.
  • The introduction of a Publish Message value to support the frontend sending MQTT messages over WebSocket via the default protocol (as implemented in Daemon, and the layer before that, in the HTTP automation). This is immediately more useful than what the PR is supposed to be limited to--you can publish messages directly to devices over MQTT along with managing automations (shhh). This also means that adding new functionality to the frontend becomes as simple as adding a parser and Daemon implementation for the new behavior...hmm.
  • Tests have been added to exercise basic WS operations (there are some drive-by tweaks in some of the other integration tests as well, and some refactoring).
  • The frontend, meanwhile, had the device page split off to a separate module. Along with this a new, very basic PublishMQTT UI was made (also see screenshot). Basic UI tests executing navigation and publishing MQTT* were added as well (*see comments).

• Speaking of tests, this PR introduces frontend tests via purescript-spec and elmish-testing-library. If this software was being made in a more professional way, test scaffolding would have been its own PR probably in advance of any actual frontend production code, or at least with the first frontend code introduced, but I kinda skipped it 😅

  • The tests themselves
  • The config and dependencies added
  • Test-running helpers in npm config, documented in README
  • It's worth noting that the WebSocket type class is motivated largely by being able to test WebSocket-dependent behavior more effectively (test instance), but so far I haven't been able to get it to work. I would expect a reviewer to ask me to get rid of this and I think they'd be right, for a number of different reasons, but I am the evil tyrant of this project so it stays (MUHAHAHAHA). See also https://github.com/ddellacosta/automation-service/pull/16/files#diff-69b57ba8de6221c4b8edcf28755b0ffb3d6b9266560a1c60320cca383762ff41R84-R100.

• Spago has been upgraded to Spago Next. There is no reason to do this other than the fact that, when I looked in the spago repo for information on overriding dependencies with local directories, I realized a new version was being introduced, and I figured I may as well just upgrade spago while I was at it. Had I been working on this at a company or if this project was used by more people than just me, I would have skipped this. None of it was too hard, but it ended up being quite involved and the entire frontend build chain and configuration setup changed, which is not something I'd want to do to other developers without a discussion, or arbitrarily change in a production environment without a lot of testing.

  Most importantly, this included swapping out my previous method of loading PureScript and associated dependencies via easy-purescript-nix for just loading the PureScript dependency directly from nix and installing the rest via npm, as the latest spago isn't available via easy-ps-nix. I'm not sure I love this, as I don't love depending on npm any more than I absolutely have to, but it's fine so far. I also want to see if I can use https://github.com/thomashoneyman/purescript-overlay or what Dennis was working on, https://github.com/purifix/purifix, but those two will have to wait for future experiments. Anyways, will use this until it is a problem. This should let me stay more up-to-date vs. being beholden to easy-ps-nix to update its dependencies, at least. ¯_(ツ)_/¯

  Changes:

  • The first big change was removing easy-ps-nix from flake.nix and replacing it with PureScript alone. I then installed a few dependencies I had previously been bringing in via nix via npm, most importantly spago.

  • Then I removed ui/spago.dhall and ui/test.dhall (prior introduction in this PR) and replaced them both with ui/spago.yaml. The test tweaks are folded into the test section there (which honestly makes more sense to me, despite the fact that I am sad Dhall is going away).

Final addendum: a bunch of Haskell dependencies got bumped too. I'm embarrassed to say I think this was a byproduct of nix tweaks when I updated spago, but I'm not sure 😅 ...on the other hand, I was finally able to bump the tls library to version 1.6.0, which removes SSLv3 support, which is nice.

P.S. it should go without saying that, because I'm the only one who reviewed this, there are almost definitely things I've missed.

[ddellacosta]

Required by hslua version bump (https://hackage.haskell.org/package/hslua-core-2.3.0/docs/HsLua-Core.html#v:loadfile).

[ddellacosta]

Addresses an issue with GlobalRegistrator in Happy Dom (via elmish-testing-library), although I'm leveraging the fact that whatever is at 18 in nix is lower than 18.18.2, apparently >= is problematic