`cabal upload -d` (no tarball argument) calls v1-haddock and fails

[ulysses4ever]

Describe the bug
This may be more of an UX bug: cabal upload never received a v2- version, and it still tries to employ some v1- ways sometimes, e.g. as I say in the title: calling v1-haddock. It doesn't seem to bother people maybe because all the online guides I see suggest to call it with a tarball that you create beforehand.

To Reproduce
Steps to reproduce the behavior:

$ git clone git@github.com:ulysses4ever/rere && cd rere && git checkout v0.2.0.2
$ cabal build # assumes v2-build, succeeds
...
$ cabal haddock --haddock-for-hackage # assumes v2-haddock, succeeds
...
$ cabal upload --documentation
Warning: this is a debug build of cabal-install with assertions enabled.
No documentation tarball specified. Building a documentation tarball with
default settings...
If you need to customise Haddock options, run 'haddock --for-hackage' first to
generate a documentation tarball.
Resolving dependencies...
Warning: solver failed to find a solution:
Could not resolve dependencies:
[__0] trying: rere-0.2.0.2 (user goal)
[__1] trying: rere:+rere-cfg
[__2] unknown package: vec (dependency of rere +rere-cfg)
[__2] fail (backjumping, conflict set: rere, vec, rere:rere-cfg)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: rere, rere:rere-cfg, vec
Trying configure anyway.
Configuring rere-0.2.0.2...
Error: [Cabal-8010]
Encountered missing or private dependencies:
    QuickCheck >=2.14.2 && <2.17 (missing)

HasCallStack backtrace:
  collectBacktraces, called at libraries/ghc-internal/src/GHC/Internal/Exception.hs:169:13 in ghc-internal:GHC.Internal.Exception
  toExceptionWithBacktrace, called at libraries/ghc-internal/src/GHC/Internal/IO.hs:260:11 in ghc-internal:GHC.Internal.IO
  throwIO, called at src/Distribution/Simple/Utils.hs:445:3 in Cabal-3.17.0.0-inplace:Distribution.Simple.Utils
  dieWithException, called at src/Distribution/Simple/Configure.hs:1621:11 in Cabal-3.17.0.0-inplace:Distribution.Simple.Configure

Expected behavior
cabal upload -d without a tarbal argument could stop (make the tarball required) or it could call v2-haddock, which seems more appropriate nowadays.

System information

• Operating system: NixOS unstable
• cabal, ghc: cabal HEAD, ghc 9.8.

Additional Context

There's an inner function, generateDocTarball, inside uploadAction. It generates the tarball by calling haddockAction, which the v1-haddock:

cabal/cabal-install/src/Distribution/Client/Main.hs

Lines 1326 to 1340 in 7ad104d

	generateDocTarball config = do
	notice verbosity $
	"No documentation tarball specified. "
	++ "Building a documentation tarball with default settings...\n"
	++ "If you need to customise Haddock options, "
	++ "run 'haddock --for-hackage' first "
	++ "to generate a documentation tarball."
	haddockAction
	(defaultHaddockFlags{haddockForHackage = Flag ForHackage})
	[]
	globalFlags
	distPref <- findSavedDistPref config NoFlag
	let mbWorkDir = flagToMaybe $ configWorkingDir $ savedConfigureFlags config
	pkg <- fmap LBI.localPkgDescr (getPersistBuildConfig mbWorkDir distPref)
	return $ getSymbolicPath distPref </> display (packageId pkg) ++ "-docs" <.> "tar.gz"

When uploadAction notices that there was no tarball passed, it calls generateDocTarball:

cabal/cabal-install/src/Distribution/Client/Main.hs

Lines 1286 to 1291 in 7ad104d

	withRepoContext verbosity globalFlags' $ \repoContext -> do
	if fromFlag (uploadDoc uploadFlags')
	then do
	when (length tarfiles > 1) $
	dieWithException verbosity UploadActionDocumentation
	tarfile <- maybe (generateDocTarball config) return $ listToMaybe tarfiles