Add task progress capability

[ccamel]

I would like to have the tasks of a job able to report their progress. Indeed, some tasks are actually long running process, and from the point of view of the user, it is valuable to have this feedback. I think it could be a good enhancement for piper.

This PR is a first proposal, fully functional though. I tried to keep it as simple as possible.

I have some questions:

• In this PR, I've introduced an additional database column. How do you plan to handle schema migrations in piper? Should I provide a migration script for this? I think so.
• I would like to improve the way a worker send back information to the Coordinator. As you will see, for the demonstration purpose I used the injected eventPublisher instance and I forged the event by hand, but that way to do is inconvenient and fragile. It would be far better to have a dedicated mechanism to emit such notification from the TaskHandler without revealing the underlying machinery.

What do you think ?

[runabol]

This looks pretty awesome @ccamel. How Do you feel about using an int (primitive) instead of Float for the getProgress() method? the int can represent a percentage of completion (0-100) and would default to 0.

[ccamel]

@creactiviti

• Regarding the use of an object instead of a primitive: well, actually, the getProgress() method returns null to denote an indeterminate/unknown progress state. For this case, I think it's not correct to return 0 since it does not represent the same thing. However, agree with you returning null is a bad practice. So, why not returning the special value -1 for this case ?
• Regarding the type int vs float: the choice mainly depends on the resolution and accuracy we want to have. Ok, as far as I see, the progress bars usually express the percentages with an integer (0-100) and not with a number with 2 decimal places as it is currently encoded in the database. I'm fine with that. So, agree with you. We can use an int.

[runabol]

Cool thanks @ccamel. The reason why I think a primitive int would work is because if you look at the TaskStatus enum a task can really only be in one of the following states:

1. CREATED
2. STARTED
3. COMPLETED
4. CANCELLED
5. FAILED

it seems reasonable to me that for any one of these a figure of 0-100 would work. What do you think?

[ccamel]

@creactiviti Yes, I see. IMHO, the only case not covered by the range [0-100] is the N/A (indeterminate) progress in situation where a task is unable to report its progress. I'm afraid that 0 may be misleading regarding the real progress of the task.

For instance, through an ui we are not able to display a progress bar with an indeterminate value when consuming the progress from the rest api of piper. In jQuery for instance, the progress bar widget has a special value for that (value is either false or an int value in the range [0-max]).

How can we manage this case? (should we?)

[runabol]

Oh I get what you're saying now. For the sake of simplicity I think I would opt to just have the progress stay at 0 until completed at which point it will turn to 100.

[ccamel]

@creactiviti That's fine with me. I amended the code with b2112ce in accordance with your last comment.

[runabol]

merged. thanks @ccamel. great work.