Replace timers with tasks

[joente]

The current timer implementation is not very intuitive and hard to use for flexible scheduling.

Instead of timers, we could create a "task" type. Like the timer, a task should accept (require) a start time and a closure (required). A repeat value option should be dropped and replaced with more flexible re-scheduling. (more later).

The closure should get itself (the task) as first argument, (this is way better than the id with the previous timers), followed by the given arguments by the argument list.

Creating a task could be done as follow:

task(start_time, closure, optional_argument_list);
// examples:
task(datetime(), || nil);
task(datetime(), |task, a, b| {
  ...
}, [a, b]); 

A Task start_time must be at least "now" or into the future. (thus never can be 0).

The arguments list should not accept more arguments than accepted by the closure. Less arguments is no problem as they can be filled with nil values like we do in ThingsDB.

A task type should accept the following functions:

Functions which do not require a change:

• task.id() : returns the Task Id.
• task.at(): returns the Task start datetime value.
• task.owner(): returns the associated user (username) to the task.
• task.closure(): returns the closure attached to the Task.
• task.err(): returns the error value attached. nil if the task has never ran before, the error is success (0) when the last run was successful.
• task.args(): returns a list with arguments attached to the Task.

Functions with a change:

• task.set_args([...]): replace the Task arguments.
• task.set_owner([...]): replace the Task owner.
• task.cancel(): cancel the Task. The task remains registered except the run_at value will be set to zero 0.
• task.del(): cancels the task if not cancelled already and delete (unsubscribe) the task. All properties of a task will be set to null. Thus, if a value is attached somewhere as a value, it will be presented as task:nil and no other functions will work on this task.

Functions must be used within the task's closure: (changes will not be created by these functions but instead after the task has finished) There is no need to mask these as change functions as the task always is guaranteed to have a change anyway.

• task.again_at: schedule a new time for the task (at least one minute after current run).
• task.again_in: shortcut for again_at(task.at().move(....)).

Example repeating task:

task(datetime(), |task| {
    task.again_in('days', 1);  // relative to the "current" task, not the actual time.
    log(`This is log from task Id {task.id()}`);
});

Calling function task with a task Id return the task with that Id. Only for as long as the task is subscribed and thus is not empty.

Function tasks() returns a list with all the tasks. This way it is also possible to manage tasks in the @thingsdb.

When a task is started:

Exception is raised	.delete() is called	.again..() is used to re-schedule	What will happen
0	0	0	=run_at unchanged, success, one time task, create a TASK_DELETE change.
0	0	1	> run_at, create a TASK_AGAIN change.
0	1	0	* null, task is already cleared and TASK_DELETE change has been created.
0	1	1	* null, task is already cleared and TASK_DELETE change has been created.
1	0	0	=run_at unchanged, create a TASK_ERROR change.
1	0	1	>run_at, create both a TASK_AGAIN and TASK_ERROR change. In that order to AGAIN can set success, and ERROR overwrites.
1	1	0	* null, task is already cleared and TASK_DELETE change has been created.
1	1	1	* null, task is already cleared and TASK_DELETE change has been created.

Related changes:

TASK_DELETE: unsubscribe and "clear" a task.
TASK_ERROR: set a task error (ex_t).
TASK_AGAIN: set the task error to 0, success and re-schedule the task.
NEW_TASK: create a new task.
SET_TASK_ARGS: set new task arguments.
SET_TASK_OWNER: set new task owner.
TASK_CANCEL: set run_at to 0. must be checked at the last time possible. (when processing the event).

Parsing a task into the str function should return task:123 or task:nil if the task is no longer subscribed.

Only the functions task and tasks must be scope restricted as the rest follows automatically.

[joente]

Implemented in v1.1.0