[settings-sync] IJPL-13931 Ensure settings categories are respected in the initial sync

[jaen]

Resolves: https://youtrack.jetbrains.com/issue/IJPL-13931/Settings-Sync-ignores-the-category-state-changing-when-enabling-sync-for-the-first-time

As far as I can tell, the Settings Sync code does send only the files you requested, but:

• it does only send files as they are on the disk – when setting up the sync, the SettingsSyncSettings state won't get persisted immediately (the IDE only does it later, after you exit settings), so another IDE wanting to use that state will show all categories enabled (even though the sync will not contain that date) until the settings get flushed,
• settings for plugins didn't get properly categorised – this mean that you could either disable the category wholesale, or you would get all the plugins when syncing.

Those issues were fixed by — respectively — adding an explicit settings flush before the initial sync and adding code to categorise plugins properly. I think this should fix the issue as perceived in the UI by an user.

[Glyphack]

Hey @The-Compiler @RonnyPfannschmidt I rebased the PR could you please take a look?

[webknjaz]

Hey @Glyphack, could you resolve the merge conflicts / rebase this?

[Glyphack]

Hey @Glyphack, could you resolve the merge conflicts / rebase this?

Yes will do today.

[Glyphack]

Thank you both for the review. I left some TODO comments I will address them in a follow up PR.

[Glyphack]

Thank you so much for the reviews. Please take another look and let me know if there are more improvements. I was busy last week I will be quicker in resolving them this time. @nicoddemus I like to help with the PR you created. I'll take a look there once this is done.

[nicoddemus]

I think @nicoddemus's intention is for you to incorporate his suggestions in this PR, this way we can review & merge everything together.

@bluetech not really, I meant to apply those later (I only created a Draft PR to not lose the local commits I made).

[bluetech]

@bluetech not really, I meant to apply those later (I only created a Draft PR to not lose the local commits I made).

Ah sorry for the assumption. The reason I thought it would be better to combine is that merging as-is would introduce a typing regression (fixture functions would lose their signature). But it's only temporary so not a problem.

[youtux]

FYI, this breaks pytest-factoryboy, but that's something I have to deal with. Just wanted to let you know, in case maybe other users could have the same issue.

That being said, __pytest_wrapped__ was an internal API, so 100% agree that there is no guaranteed behavior on these.