Make '--env-file' option top-level only and fix failure with subcommands

[KlaasH]

Resolves #6746

The --env-file option added in PR #6535 makes sense as a top-level option but was added both to TopLevelCommand and to some subcommands. At best, the handling in the subcommands is redundant and muddies the waters; at worst, it causes bugs, like the fact that, as noted by @digitalist, docker-compose --env-file=custom.env up doesn't work, loading the .env file despite the attempt to override it.

So this removes the option from build, up, and down; moves the handling of the option into a method on TopLevelCommand; and changes the naming a bit to emphasize that this is a top-level option that controls the top-level environment (I've also been thinking of it as "project-level", as opposed to "service-level").

Testing

This does two main things:

• Removes the --env-file option from the build, up, and down subcommands. You can see that in their usage messages (which you can view by trying to put the option after the subcommand...)
• Resolves the issue whereby mishandling by some subcommands caused the top-level option to be ignored. For that, you can do something like this, which creates a simple docker-compose.yml and a few env files and runs a command to show that the override is happening (do it in a new directory to avoid clobbering anything important):

cat <<\EOF > docker-compose.yml
version: '3.7'
services:
  test:
    image: busybox
    env_file: .env.conf
    entrypoint: env
EOF

echo 'WHEREAMI=default' > .env
echo "This won't parse as a variable" >> .env
echo 'WHEREAMI' > .env.conf
echo 'DEFAULT_CONF_LOADED=true' >> .env.conf
echo 'WHEREAMI=override' > .env.override

docker-compose --env-file .env.override up

The output will include WHEREAMI=override when it's working. When it's not, i.e. on master, it'll produce an error saying there can't be whitespace in a variable name.

This doesn't add any cases to the test suite because I couldn't really think of good cases to test. PR #6535 added tests for the "working override" case and there were already tests for the "working default" case, and this mostly removes the stuff that's not covered by those. Adding a test that e.g. up works the same as config seems like it would take a bit of doing and wouldn't test anything very interesting under the circumstances.

[GordonTheTurtle]

Please sign your commits following these rules:
https://github.com/moby/moby/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:

$ git clone -b "revise-env-file-option" git@github.com:KlaasH/compose.git somewhere
$ cd somewhere
$ git rebase -i HEAD~842358785968
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.

[KlaasH]

Rebased to resolve conflict with 9d2508c.

[ulyssessouza]

Just a little consideration on the last modification about using the same method

[ulyssessouza]

Why not using use_cli = not self.toplevel_environment.get_boolean('COMPOSE_INTERACTIVE_NO_CLI') here too?

[KlaasH]

This is a stand-alone function, not a method of TopLevelCommand. Though it seems like it's only called in TopLevelCommand.run, so adding an argument to pass toplevel_environment in could work fine and remove this duplication.

[KlaasH]

Added a commit to do this--replaced the project_dir argument (which was only used for this) with a toplevel_environment argument.

[ulyssessouza]

Cool! I didn't have enough context in the browser based diff to see that.

[rumpl]

We should update the bash completion scripts in this PR too.

[KlaasH]

Added --env-file completions for bash, fish, and zsh.

[KlaasH]

Rebased onto master to resolve conflict with #6813.

[ulyssessouza]

LGTM