chore: Add additional logs for state transitions

[darunrs]

I added a little bit more logging to the lifecycle state changes, as well as renamed the Stopping/Stopped states to Suspending/Suspended states to more accurately capture the intention.

[darunrs]

Thinking of adding unit tests to lifecycle, where I just test that the handle_[state] functions do what we expect. This requires importing a LOT of mocked things. Not totally sure what's the cleanest way of doing that. I thought of two ways:

1. Implement an auto mock for all three handler structs and use them
2. Create actual handlers, with mocked things like redis, wrappers, etc.

I initially thought to do 1 but now I'm starting to feel 2 might be better?

[morgsmccauley]

This would set any state that isn't Stopping to Suspended right? We should only set this if it is Stopped. We probably need to map each state specifically since we have two types.

[darunrs]

So I tested this locally, and it actually doesn't reach this part of the function, unless the initial parse fails. So, all the other options ended up getting parsed correctly, and the only ones which went here, were the states which are no longer part of Lifecycle.

I verified this in the below unit test. I have four states to parse: Initializing, Running, Stopping, and Stopped. The redis state set call was only called twice, and they were called with the correct Suspending and Suspended state respectively.

I don't mind being explicit here though.

[morgsmccauley]

Ah you're right, we'd only get here if parsing fails, which would only be for Stopping/Stopped. I'm fine leaving it as is then :)

[darunrs]

Moved the if statement to a separate variable assignment. I'll be able to put some warn logs out if there's an unexpected input.