Transaction Fix

Fix bug in settings engine that can cause unnecessary conflicts to appear upon sync failure in certain situations, typically when an app writes a file (v1), then a short time later rewrites the same file (v2) with different data. Because remote changes were not (prior to this change) in their own transaction, v1 would get picked up and written to both local and remote, then when app is flushing database changes back to the local machine, it would notice the file on disk was v2 (different) and fail the sync (by design), rolling back the local transaction, but leaving v1 in the remote db. Autosync would then try to sync the product again, pickup v2 into the local, and find it conflicts with v1 in the remote. In reality, both v1 and v2 came from the local machine, so there should be no conflict, and putting the remote database operations in a transaction fixes that.

I previously thought remote changes shouldn't be in a transaction, because remote doesn't need to be in perfect sync state with any local files, so propagating more changes should always be a good thing. This case makes it clear that is wrong.

Also remove parameter from CfgEnumerateProducts() that is not used and has not worked for a long time anyway.