HandlerAppStatus needs to send initial apps status

[giulio93]

Motivation

The client needs to be informed of the actual status of each app status, before handling any events coming from docker.

[Xayton]

Some things I noticed while testing the feature. Some might not be related to the changes of this PR, but already present in the previous feature development.

Most of the things below would probably go in future tasks.

• (low priority) We can probably return only the id of an app, the name (for readability) and the changed properties (normally only the status).
• when connecting to the endpoint, I only get the status of apps for which there is a status. Most of the examples are not listed, some (if they have been already run once) are listed. This looks strange and wrong (even if it is the same behavior of our list operation)
• When stopping and app I get 2 messages (a "running" one followed by a "stopped" one). I think I should only receive a "stopped" one.
• We should probably have a "starting" status

[lucarin91]

(low priority) We can probably return only the id of an app, the name (for readability), and the changed properties (normally only the status).

I think we can discuss the amount of info in another issue, but I would keep the same model of list endpoint, to avoid both to model too many things and also reducing the possibility of the user needing to do a subsequent request.

when connecting to the endpoint, I only get the status of apps for which there is a status. Most of the examples are not listed, some (if they have been already run once) are listed. This looks strange and wrong (even if it is the same behavior of our list operation)

I think that exactly the point the endpoint return the status update, if an app has no status why we should list it

When stopping and app I get 2 messages (a "running" one followed by a "stopped" one). I think I should only receive a "stopped" one.

We can should open a ticket about that. That depends on the way we evaluate the app status. I can andicipate that it will not simple to reduce this fluctuation. Anyway, I don't see any issue in having multiple events if they return the correct state, there wasn't any constraint about that.

We should probably have a "starting" status

This is related to the one above we have a starting status but it isn't triggered correctly