Allow klipper-mcu-added.sh to send a RESTART command to the printer

[ChrisWeinman]

Allow klipper-mcu-added.sh to send a RESTART command to the printer, even if the printer file is a symlink in a directory with the sticky bit set. Improve logging

Symlinks cannot be followed if they are in a directory with the sticky bit set, like /tmp, if the symlink is owned by a different user.
This causes [ -e /tmp/printer ] to evaluate to false. This also means that trying to write to /tmp/printer fails unless the user owns the /tmp/printer symlink.

Added a loop to keep dereferencing until either the -e test evaluates true or no longer testing a symlink.

With this change, powering up the MCU while klippy is running results in RESTART being sent to /tmp/printer and the printer becoming usable without any user intervention.

[miklschmidt]

Oh, very nice, thank you. However, I think this is better solved by calling a configurator endpoint that checks the state of klipper before restarting, so plugging in a board won't resolve in a botched print job. Furthermore this would also result in some possibly unexpected behavior during board flashing, so it has kind of been left in a "not working" state for a while.

Will have to think so more about what we do about this, because i do still like the idea. Appreciate the effort! will leave this open for now.

[ChrisWeinman]

Ah, I couldn't get hold of a Raspberry Pi when I built my printer so I'm not using a full RatOS install and haven't looked at the configurator. I agree, that is probably the right place for it, or at least query the configurator to determine if a firmware update is in progress.

Checking against klipper state is pretty straightforward, we could just query moonraker and only send the restart command if the reported state is "shutdown" or "error"

state=$(curl http://localhost:7125/printer/info | python3 -c "import sys, json; print(json.load(sys.stdin)['result']['state'])")

I couldn't find a clean way to query klipper directly using the klipper API without installing other packages or writing a, so this means adding a dependency on moonraker. If this will depend on moonraker anyway, it probably makes more sense to just use that to issue the restart command rather than jumping through hoops to get symlinks to work.

The firmware update case is trickier, especially with many different MCUs with different flash methods. I suspect it might "just work", as the MCU likely comes up with a different USB ID when in DFU mode and so the udev rule that calls this script won't fire, but I wouldn't be comfortable assuming that's the case for all boards.

I'll update the PR to check the state of klipper and leave it here for reference.