Bug 1536635

Description of problem:
After having fixed the problems that were preventing the VDO Ansible module from interacting with VDO (bug 1536214 and bug 1536522), I found that the module was running in a way that would always return a "changed" value of "True" if the state of deduplication or compression were changed, regardless of whether the operation actually did run.  This is incorrect; if the playbook tries to change something, and fails in a way that results in no change, it should show a "changed" return status for that task.

Version-Release number of selected component (if applicable):
vdo-6.1.0.114-14.x86_64

How reproducible:
This would only appear if the "vdo enableCompression", "vdo disableCompression", "vdo enableDeduplication", or "vdo disableDeduplication" call were to fail

Steps to Reproduce:
1. Install the vdo.py ansible module to the Ansible ".../modules/system" subdirectory of the system to run VDO, and a control system.
2. Copy one of the example playbooks from the /usr/share/doc/vdo/examples/ansible directory of the system with VDO to the control system, and create a playbook that uses a local username, acts on a block device existing on the system, and has various other parameters.  

Recommended sequence: use /usr/share/doc/vdo/examples/ansible/test_vdocreate.yml as a base for a creation playbook, /usr/share/doc/vdo/examples/ansible/test_vdoremove.yml as a base for a removal playbook.

3. Create a copy of the modified "test_vdocreate.yml", with the following additional lines:

- test_vdocreate_yescompress.yml: "compression: enabled"
- test_vdocreate_nocompress.yml: "compression: disabled"
- test_vdocreate_yesdedupe.yml: "deduplication: enabled"
- test_vdocreate_nodedupe.yml: "deduplication: disabled"

4. On the control system, after passwordless ssh has been established, execute "ansible-playbook <playbook_filename.yml>".  Run the "test_vdocreate.yml" equivalent script to create the VDO volume, and then run "test_vdocreate_nodedupe.yml" to disable deduplication.

Actual results:
The "changed" status for a compression or deduplication status change will be "True", regardless of outcome.

Expected results:
The "changed" status for a compression or deduplication status change will be "True" only if the return code from that call is 0 (success).

Additional info: