#31 Restore paddle, stop and trip information on process interruption [DIU]

If the paddlemgr (paddle manager) process is interrupted, by exiting and then being restored via the client_supervisor, say, the paddle, stop and trip information is reset to zero.

This has the effect of having fares show up in the billing_log with 0 entries for driver, paddle, stop and trip.

The new state_info system has stored state that is loaded by any process that needs it with writing being funneled through the client_supervisor process only to minimize race conditions. The driver, paddle, trip and stop information can be loaded by the paddlemgr process on start (and HUP?) but this state might need to be communicated to the other processes.

In paddlemgr.c, there is a send_status_update() function. One possibility is to load the state information on start, then proceed to do a send_status_update() once the line to the IPC server has been established.

My only hesitation is that if this then triggers some other paddle, trip or stop update, this could get into an infinite ping pong of messages.