Cabal checks extra-tool-paths before it needs them.

[Mistuke]

Describe the bug
@hvr suggested using pkg-config-location as a workaround for #6304.

The problem however is that cabal checks if the paths to these tools exist even when it doesn't make a call to
use the tools. The issue this is causing is that when installing cabal through chocolatey I would like to make it as friction less as possible. Installing msys2 is not a hard requirement and I can't guarantee the order in which cabal and msys2 are installed.

So I pre-populate the pkg-config-location with the expected paths to msys2. But then this makes it unusable if msys2 isn't installed at some point since cabal will bail out saying the path can't be found.

Which is perfectly reasonable if it was doing something requiring the tool at that point, but if it's not it shouldn't. This allows flexibily in setting up cabal with optional dependencies.

side note: It would be very neat if you could specify in the config file which command the user can run to install the missing tool. i.e. if I could say something To install pkg-config run 'mingw64-pkg install pkg-config' to install this tool.

To Reproduce

cabal user-config update -a 'program-locations' -a ' pkg-config-location: C:\pkg-config.exe'
cabal v2-repl

Expected behavior

I expect ghci to start up and not cabal failing with C:\pkg-confi.exe not found.

System information

• Windows 10
• cabal 3.0.0.0 GHC 8.8.1

Additional context
I currently require the user to re-install the cabal package after they install msys2 and after they install pkg-config, but that's not very obvious and not very friction free.

[gbaz]

This is intended behavior, according to this comment:

cabal/Cabal/src/Distribution/Simple/Program/Db.hs

Lines 318 to 321 in 00a2351

	-- Note that it is not a failure if the program cannot be configured. It's only
	-- a failure if the user supplied a location and the program could not be found
	-- at that location.
	--

I'm not sure if we should change this? On the one hand, it seems to be good to eagerly error when an explicitly specified program does not exist. On the other hand, lazily erroring when it matters won't cause any regression in semantics..

Further, I think given that there's an impending patch for #6304 its not clear to me if there's ever going to be a need for this?

I'll mark low priority for now, and let @Mistuke comment if it seems like it should still be addressed.