nvda

89798801 - Fix various issues when removing add-ns and improve state management in `addonHandler` (#12792)

Fix various issues when removing add-ns and improve state management in `addonHandler` (#12792) Fixes #12629 Summary of the issue: As described in #12629 it is impossible to update add-on when its folder is opened when initiating upgrade. During investigation I also encountered various other errors during add-on removal in particular: - If a disabled add-on is uninstalled and then reinstalled it stays disabled even though source code comments clearly states that it should not be happening. - If a folder of the add-on is renamed and its name no longer agrees with the name in the manifest it cannot be uninstalled via add-ons manager and there is absolutely no indication in the log as to what went wrong. Description of how this pull request fixes the issue: 1. addon installation cannot be finished when add-on folder was opened during installation was caused by the fact that after attempting to install add-ons pending installation list of all add-ons pending install was emptied even if the given add-on failed to install. This has been fixed by removing add-ons from list of pending installs only if installation was successful - otherwise NVDA would retry on the next restart. In addition for configurations which can be potentially affected by this I've also made sure that for all folders which name ends with suffix denoting add-ons pending installation NVDA tries to install them regardless of their presence on the list. 2. disabled addons are not removed from the list of disabled add-ons after uninstallation was caused by the fact that there were two lists of disabled add-ons. The first one in the state and the second one _disabledAddons was duplicating content of the list in the state Unfortunately the second list was populated after add-ons were removed yet names of the disabled plugins were removed from it rather than from the list in the state. This has been fixed by no longer using _disabledAddons at all - it ended up to create more confusion than it is worth and added no real benefits. I've also make sure that for old configs all add-ons which are no longer installed which are present in the list of disabled add-ons are removed. 3. addons for which directory is named differently than the name in the manifest was solved by uninstalling add-ons after getting manifest data i.e. no longer rely on directory name matching the manifest name. In the process I've also made addons state a class which has methods for loading, saving etc. rather than just having a simple dict with various top level function operating on it. This is backwards compatible. Testing strategy: Made sure that state created by previous version of NVDA can be successfully loaded Made sure that state created by the code from this PR can be successfully read by previous versions of NVDA Renamed folder of an add-on so that name of the directory is different than the name in the manifest - made sure that it can be uninstalled from add-ons manager Uninstalled disabled add-on - made sure that it is removed from the list of disabled add-ons in the state Opened folder of an add-on in Windows Explorer, tried to update the plugin, closed the opened folder - made sure that after NVDA restart add-on has been successfully installed.