Pass set of node-ids in jobs so that anyone from the list can pick it

[shtripat]

Enable job execution framework in tendrl to set set of node-ids in the job submitted to central store. One of the agents running on the storage nodes, would pick the job if their node-id falls in this list. This enables targeting a job to a set of nodes rather than to a specific node (of course the list can have only one entry and a job can be targeted to a specific node as well :)

[shtripat]

Being taken care as part of #104

[r0h4n]

Currently, the node-agents pick up jobs based on round robin method, and in future with node tagging, the tags will also be used to map jobs to node agents.

Why do we need this?

[shtripat]

@r0h4n as per discussion with @brainfunked last week, we may need to target job to a set of nodes and any one from that list can pick as process. It could case like we want the job to be picked by any of the mons in the ceph cluster, and in tha case task can populate node_ids value to the set of ids of mons in the cluster and create job in queue.
This is actually complementing to #44. So if a node_agent is not tagged and job contains a list of node_ids mentioned, any node from that set can pick the job and process. Tags would get preference over node_ids parameter. So if a node_agent is tagged with certain value and job is targeted for that kind of tag, job could be picked by this node agent. If no tags then node_ids parameter from job would be taken into consideration.

@brainfunked @nnDarshan comments?

[brainfunked]

We need restrict the distribution of the jobs such that they would be picked up by one of the nodes in a specific group. This came to originate from the import and create cluster workflows. In these workflows, it is necessary to enable the user to select specific targets for jobs to be executed upon.

Some additional thoughts. With the bridges, they should all have hardcoded logic to decide which instance should pick up a particular job.. Rather than tying this to a specific node, in case of bridges, the logic should be purely role based, where currently, the roles are all hardcoded in the bridges (not explicitly, but based on the logic that distributes the jobs among bridges using the metadata of the job). The reason behind this is that this is an implementation detail hard-bound to a specific storage system. The entity invoking a job (user, node agent, whomsoever) must not need to know how it gets implemented on the storage system side. Hence, I think this patch should apply only to the node agents and not the bridges. As is already the case, the bridges should have hardcoded logic to decide which instance picks up a particular job.