Fix config group implementation to support edge cases

The current config group implementation causes inconsistent state in some scenarios.

Consider this example for mysql:

Assume config group : configtest => {u'autocommit': 1, u'max_user_connections': 50, u'max_connections': 50} . All 3 parameters do not require a restart. This config group is applied to instance A.
Later configtest is updated using this command : trove configuration-update <config_test_id> '{"autocommit": 0} .
Here max_connections & max_user_connections are deleted from the config group using the update command. However since the param in the updated config group, autocommit, does not require a restart, the update operation as a whole does not require a restart. The values of max_connections & max_user_connections are not updated to their respective defaults on instance A. This leads to inconsistent states.

Similarly consider this other example:
Assume config group : configtest1 => {u'autocommit': 1}
This config group is applied to instance A.
Assume config group : configtest2 => { u'max_user_connections': 50}
Both these config groups contain parameters that do not require a restart.
When configtest2 is applied to instance A without detaching configtest1, it leads to inconsistent state. autocommit will hold the value 1 on instance A rather than the default value for autocommit.

As an enhancement to the current implementation, the guest agent should handle these edge use-cases & make a decision on whether the instance requires a restart or not, depending on the config group operation.