Monitor imported cabal.project files

[philderbeast]

• Fixes Changing a file imported by cabal.project does not trigger recompilation #10255.
• Depends on Add project monitoring logging #12069.

I started with #11567 by @hasufell.

I then reverted a lot of changes not related to (or no longer needed for) monitoring before attempting a rebase. To make the rebase easier I also squashed those changes into one commit.

I then rebased over master once #10933 merged, so that we could match on whether an import was local file or a URI.

Important

This pull request avoids taking on this redesign:

- newtype ProjectConfigPath = ProjectConfigPath (NonEmpty FilePath)
+ data ProjectConfigPath = PCPWithImports PCPLeaf (NonEmpty FilePath)
+                       | PCPWithoutImports FilePath
+    deriving (Eq, Show, Generic)
+
+ data PCPLeaf = PCPFilePath FilePath
+             | PCPURI URI
+    deriving (Eq, Show, Generic)

I redesigned ProjectConfigPath, because I did not like how we stuff URIs into FilePaths
-- #11567 (comment)

That is not to say we shouldn't do this or something similar but it is not needed to fix project file monitoring. ProjectNode could maybe help in a future redesign?

cabal/cabal-install/src/Distribution/Client/ProjectConfig/Import.hs

Lines 85 to 90 in 92829a5

	-- | Isomorphic with 'ProjectConfigPath' but with separate constructors for the
	-- root, imported file and imported URI.
	data ProjectNode a where
	ProjectRoot :: FilePath -> ProjectNode ProjectFilePath
	ProjectFileImport :: FilePath -> ProjectConfigPath -> ProjectNode FilePath
	ProjectUriImport :: URI -> ProjectConfigPath -> ProjectNode URI

Note

I changed these items after rebasing:

• Fix the -Wunused-top-binds warning for lookupLocalPackageConfig by re-exporting deleting it
• Avoid the many primes of lookupPerPkgOption'
• Avoid duplicates when monitoring
• Watch out for explicit imports of cabal.project.local and cabal.project.freeze

I'll squash commits before applying the merge label if this pull request is approved.

---

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
  • Is the change significant? If so, remember to add significance: significant in the changelog file.
• The documentation has been updated, if necessary.
• Manual QA notes have been included.
• Tests have been added. (Ask for help if you don’t know how to write them! Ask for an exemption if tests are too complex for too little coverage!)

[philderbeast]

Putting this back to draft. I've added some debug logging and found more things to test for and other issues to raise.

[philderbeast]

Closing in favour of #12077 and #12080. Tests were added already in #12069.