PR Summary

Fix #7452

Background about the setting DisablePromptToUpdateHelp:

In Windows PowerShell, DisablePromptToUpdateHelp is a registry key property set at HKLM\SOFTWARE\Microsoft\PowerShell.
It's not really a setting for user to configure PowerShell, but instead, an implementation detail. It's used by Get-Help to tell if Update-Help has been run yet. On a fresh Windows, DisablePromptToUpdateHelp is not set, so Get-Help running in a admin privilege PowerShell session will prompt user to ask if the user wants to run Update-Help to download help content for all the modules in module path. DisablePromptToUpdateHelp then is set to 1 after the prompt (Update-Help will set it to 1 too), so the code that prompt and run Update-Help in Get-Help is guaranteed to execute only once.

This feature never worked in pwsh, because when moving the registry settings to the powershell.config.json file, UpdatableHelpSystem.ShouldPromptToUpdateHelp() was not updated correctly to keep the previous behavior. However, that was not a bad thing because the previous behavior in Windows PowerShell is not appropriate to pwsh anymore:

• for powershell.exe, there is only one instance of PowerShell, so the DisablePromptToUpdateHelp key in registry can guarantee the prompt from Get-Help shows up only once.
• for pwsh.exe, there can be many instances of PowerShell, and they all depend on their own $PSHOME\powershell.config.json, so even if Update-Help has been run, a new instance of pwsh would still show the prompt when you run Get-Help in it. This is not desirable.

Given the fact that:

1. this feature never worked in pwsh and there has been no complaint about it;
2. the feature implementation in Windows PowerShell doesn't work for pwsh

I propose to remove this functionality from pwsh, so as to remove the DisablePromptToUpdateHelp setting from powershell.config.json file (it should never be there as an implementation detail).
If we decide to bring back this functionality to pwsh in future, the implementation definitely needs to be re-written.

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• Breaking changes
  • None
  • OR
  • Experimental feature(s) needed
    • Experimental feature name(s):
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed
• Tooling
  • I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
  • OR
  • I have considered the user experience from a tooling perspective and enumerated concerns in the summary. This may include:
    • Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode (which runs in a different PS Host).
    • Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
    • Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
    • Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).