Reconsider parameter names for yaml and type about nosqlbench

[michaelsembwever]

It would be great if the new user experience was…

It's as simple as
./nb run

If you want to do something more than a key-value workload, like time-series, it's just
./nb run workload=baselines/time-series

If you want to load nodes that are remote, it's just
./nb run hosts=…

If you want to generate load from a different driver, it's just
./nb run driver=kafka

--
A lot of new users get on board via a tactile learning approach. This gives it to them.
Not to mention, half the time Cassandra dev/ops use stress it's nothing more than putting anything through a node to generate some activity, needing nothing more than the ./nb run invocation. Going down this route, then the new names of the parameters as used above (IMHO) land better.

[phact]

@michaelsembwever we're doing some related improvements in another issue that I think you'll like-
#67.

This particular issue is around considering adding synonyms for the current terms yaml and type.

I don't particularly love driver but it may be the best we can do. @jshook thoughts?

[jshook]

The word driver by itself can lead to confusion, because there is a whole layer of additional functionality that we add for testing purposes on top of the native driver.
We might consider other alternatives like "adapter" or "protocol" without overloading the term driver too much.

[jshook]

I'm coming around on the idea of using 'driver' here. As long as we make it a clearly documented synonym, I think it may address everyone's concerns.

I agree that 'type' is a big vague, and 'activity-type' and all that it implies is overly detailed if you are coming to this toolkit from no prior knowledge.

[phact]

Addressed here #89

[jshook]

This has been addressed. We're doing minor refinements on the named scenarios support to make it better.