Switch from call_id to task_id for consistency

[denismakogon]

As part of async execution HTTP API response IronFunctions returns call_id. But it's actually referring to task ID (from models.Task). In order to keep consistency between tasks objects (that are available via /tasks HTTP API) that are containing task_id and no call_id it is necessary to rename call_id to task_id.

This patch renames call_id that comes as part of API response on async execution request to task_id for API consistency purposes.

HTTP API impact: call_id renamed to task_id

Partially addresses: #415

[treeder]

Is this only for async functions? We named them call_id in reference to a "functions calls", not sure we should have task_id and call_id.

[denismakogon]

@treeder the thing is that Async execution returns call_id, but I need to query /tasks to get info on it. So, for implementing /tasks/{task_id} we need to clarify what we return to a users, would it be call_id or taks_id that can be tracked via /tasks

[denismakogon]

@seiflotfy @pedronasser @treeder Guys, can we make certain decision on this one?

[seiflotfy]

So I am pretty ok with that change, we are not 1.0 and I like the changes to the docs.
I'd like to have a +1 from @pedronasser @treeder @ccirello
Then lets push it through. Also can you make sure you add a note in the changelogs?

[seiflotfy]

LGTM

[ucirello]

A good merge message covering on the reason and consequences of this change is a must. Regarding everything else, LGTM.

[treeder]

The main thing that bugs me about this is having different names for essentially the same thing. We should choose one or the other across the board.

[denismakogon]

@treeder isn't task_id fits better here rather than call_id?

[CLAassistant]

All committers have signed the CLA.

[ucirello]

I am just trying to decouple my account from this.