Prompt for RelativeFilePaths in interactive update

[mdanish-kh]

• Have you signed the Contributor License Agreement?
• Are you working against an Issue?
  • Resolves Prompt for RelativeFilePaths if client cannot auto-detect #430

Examples manifests to test with are included in the linked issue

Unmatched RelativeFilePaths can be categorized into 2 types with this PR

CASE-I Same binary name, different directory name

a. Single match for example.exe in the new archive

e.g. Example-1.2\example.exe -> Example-1.3\example.exe

In this case the autonomous and interactive update logic will auto-detect the new binary from the archive and user does not have to do anything.

b. Multiple matches for example.exe in the new archive

e.g. Example-1.2\win64\example.exe matches with Example-1.3\win64\example.exe and Example-1.3\win32\example.exe in the new archive.

In this case the autonomous update will fail as it cannot disambiguate which example.exe to use as the new RelativeFilePath (although the above example makes it seem obvious which to choose but we need a way to generalize for any case). Interactive update will match for all example.exe in the new archive and prompt the user to select one

CASE-II Different binary name under different directories

e.g. Example-1.2\example-1.2.exe -> Example-1.3\example-1.3.exe

Autonomous update will fail again for same reasons. Interactive update will now scan for all .exe (old relativefilepath extension) in the new archive and prompt the user to select one of them as new RelativeFilePath. If there are no .exe files in the new archive, the interactive update can't move any forward and an appropriate message is printed.

---

Microsoft Reviewers: codeflow:open?pullrequest=#431

[ryfu-msft]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).