Windows: Update GVFS.Service to more aggressively remove non-inbox ProjFS

We've seen support issues where VFS4G fails to run after being upgraded (or after being re-installed) on RS4+ Windows machines.

To address these issues GVFS.Service should be updated to always remove broken non-inbox ProjFS installations (i.e. those where the service is installed but the native dll is missing)

Details from email discussion:

The issue in the thread below could have been avoided if GVFS more aggressively removed non-inbox ProjFS.

The first indication that things were going wrong was when GVFS.Service detected that the native DLL was missing:

[10/5/2018 4:57:02 AM] TryEnablePrjFlt_Summary {"Area":"EnableAndAttachProjFSHandler","Initial_isRunning":true,"Initial_isServiceInstalled":true,"Initial_isDriverFileInstalled":true,
[10/5/2018 4:58:50 AM] IsNativeLibInstalled {"Area":"ProjFSFilter","system32Path":"C:\WINDOWS\system32\ProjectedFSLib.dll","existsInSystem32":false,"gvfsAppDirectory":"C:\Program Files\GVFS","appFilePath":"C:\Program Files\GVFS\ProjectedFSLib.dll","installFilePath":"C:\Program Files\GVFS\ProjFS\ProjectedFSLib.dll","existsInAppDirectory":false}
[10/5/2018 4:58:50 AM] Error {"ErrorMessage":"TryEnablePrjFlt: Native library is not installed"}

A machine can get into this state when prjflt.inf is not found during the GVFS installation process because the presence of the file determines if the non-inbox ProjFS will be removed. Once a machine gets into this state manual intervention is always required to repair the installation.

We do have some options for addressing this pain point:

• Update the GVFS installer to always remove non-inbox ProjFS
• Update GVFS.Service to remove the prjflt service when it finds the native DLL is missing (and inbox ProjFS is not enabled), and then install\enabled ProjFS again.

Thoughts on implementing one (or both) of these options?

Historically we’ve avoided removing ProjFS when the .inf file was missing because:

• The GVFS installer would use the .inf to uninstall ProjFS
• Concerns that we could disrupt other providers by removing ProjFS

However, the installer no longer uses the .inf to remove ProjFS and the repair steps we provide users are the same steps described above (and we’ve not run into problems with breaking other providers).

Note that once all users are on RS4+ and switched to using inbox ProjFS this will no longer be an issue.

Start in GVFS.Service's ProjFS enable and repair flow, especially the IsNativeLibInstalled check and handling of the prjflt service. Confirm that a missing native DLL with inbox ProjFS disabled removes the broken non-inbox installation, then installs or enables ProjFS again; validate the behavior with the existing service tests if available.