Since WC 3.3.1, the following query is executed on every page load:
```
UPDATE `wp_options` SET `option_value` = '1' WHERE `option_name` = 'current_theme_supports_woocommerce'
```
This is happening because of the following call to `update_option()`:
```
update_option( 'current_theme_supports_woocommerce', current_theme_supports( 'woocommerce' ) ? 1 : 0 )
```
(02cac7d637/includes/class-wc-post-types.php (L268))
`update_option()` shouldn't update the option when the value hasn't changed, but in this case it is updating on every request because, when the current theme supports WC, `1` (integer) is passed to `update_option()` and this function internally compares it against the old value stored in the database which is `"1"` (string). A strict comparison (`===`) is used (f3eaddd2dc/wp-includes/option.php (L343)), so the function assumes that the value changed and proceeds with the update.
This PR fixes this problem by using the values `"yes"` and `"no"` instead of `1` and `0`.
WC doesn't support downgrades but the if condition that decides whether or not to call WC_Install::install() and apply database schema changes was checking if the WC version stored in the database is equal to the WC version in the code. This commit changes the check performed inside the if condition to verify if the WC version stored in the database is smaller than the version in the code. This way `dbDelta()` won't be called automatically by WC and revert database schema changes. This is particulary important for clustered providers where the version of the WC code running in one of the containers could be outdated and trigger a database downgrade.
To test the method WC_Install::check_version() it is not necessary to update the of the option 'woocoommerce_db_version' as this method uses only 'woocommerce_version'.
Removed the print_r() call as phpcs was complaining about it and there is no need to output the version values as phpunit will do that if the test fails.