allow read_can to reconnect on Siren connection failure

[tszwinglitw]

Modified the read_can function to improve resilience to connection failures. Instead of exiting on a connection failure with .except(), the function now attempts to reconnect, utilizing the automatic_reconnect interval options defined in mqtt.rs.

Tested to withstand disconnections to mosquitto service (on launch or in-session).

[jr1221]

I will test this tommorow and report back.

One thing I noticed is this only applies to the read_can thread, but it needs to apply to the read_siren encoder thread as well. The reason your testing worked is because the read_siren is an optional feature. You can see how to enable it with cargo run -- -h. I think it's cargo run -- -e. So if you could just add the logic into the encoder (read_siren) that would be epic. Testing functionality of the encoder is considerably harder and something I can show you on Sunday.
Note I did add some rudimentary reconnect as that thread receives MQTT messages rather than sends them. Again we can talk more Sunday.

A few notes about some CI for the future.

At NER, you can just create a new branch in this repository rather than forking. You can name your branch <issue_id>-name, so for example this could be 50-siren-reconnect.

Right before committing try to run cargo fmt and cargo clippy. It's not a big deal if you forget becuase the CI will tell you as you just saw.

The rest of the PR conventions I will add in starting in future PRs.

[jr1221]

There may be a few lines you do not need. Other than that looks good. Interesting choice to continue to run the publish even if we failed to reconnect, I do like it as it clears the can message queue. It may need some edits when we test it next bay time.