Read coursier env vars via Task.Input

[alexarchambault]

This makes Mill read all environment variables and Java properties used by coursier via a Task.Input.

In more detail, this adds a CoursierConfigModule external module in scalalib. It contains a single Task.Input, that reads all environment variables used by coursier via Task.env and all Java properties used by coursier via sys.props.

Helper tasks compute default values for various parameters (repositories, cache location, etc.). CoursierConfigModule.coursierConfig returns most of these parameters in a case class defined in Mill, CoursierConfig. For convenience, down-the-line, we pass CoursierConfig instances around.

Fixes #5134 (by managing coursier env vars / Java properties via Task.Input)

Fixes #5229 (via coursier/coursier#3426 from coursier 2.1.25-M14 and the small rework of default repository handling)

[lefou]

The most tricky case with long running daemon is the case where the env variable is defined initially, but later gets removed from the env, in which case we need to fall back to the other defaults. Do we have this in a test case already?

[lefou]

Looks good. Found two other nits.

Could you also clean installation-ide.adoc which references the issues you just fixed?

mill/website/docs/modules/ROOT/pages/cli/installation-ide.adoc

Lines 277 to 278 in 2ee59e4

	NOTE: Currently, you may need to `./mill shutdown` before calling Mill with the environment variable to make sure it gets properly propagated to Mill's background daemon.
	There is an https://github.com/com-lihaoyi/mill/issues/5134[open issue] to let Mill detect these changes automatically.

[lefou]

Looks like a candidate for caching, to me.

Suggested change

	def coursierConfig: Task[mill.util.CoursierConfig] = Task.Anon {
	def coursierConfig: Task[mill.util.CoursierConfig] = Task {

[alexarchambault]

I've been trying that. Some abstract classes are involved (coursier.core.Repository, coursier.params.Mirror, coursier.credentials.Credentials in particular), which can be worked around, given this class is parsed from a bunch of strings, and the class instances are actually only simple easy-to-serialize classes.

But it seems this can also involve credentials (parsed from files on disk in particular). This raises security concerns: we don't adjust permissions of files where task results are written, so we could end up writing passwords in files with too loose permissions.

[lefou]

Let's leave it as-is then. Would be nice to have some support for secret caching (e.g. via encryption, or just in memory), but we currently don't.

[lihaoyi]

I think this looks fine, once the last set of review comments have been resolve we can merge this