JCLOUDS-624 - Fixed bug in ListNodes

Details can be found at: https://issues.apache.org/jira/browse/JCLOUDS-624

Any suggestions are very welcome!

To fix this bug, I used the approach debated in the above link: create
new methods to do the operation using an ExecutorService provided by the
user.The the old methods are still working, but now the operations in
these methods are not concurrent anymore!
Never is late for a discussion to improve things, even if PRs are merged! :)

I understand what you mean, but in this case it might be different.

The Chef API does not return the entire objects in the list operations; it just returns the name, URL, and a few more fields. If you want to get the list of nodes (or any object) with all the information populated, you need to perform first a list operation and then a get one for each of the returned nodes.

This is why this "rich list" functionality is implemented as separate strategies instead of being part of the ChefApi itself.

The options approach applies usually to APIs that "understand" the options parametes and can perform filtering, pagination, etc, on the server side, but that's not the case of the Chef API. The way you get the list of nodes and how you get the details of each one is up to the client, and I think it makes sense to provide the methods that accept no parameters or an executor in the strategies, and leave the options approach for things that are really supported in the api.

Does this make sense? (I also love this kind of design discussions :)).