Improve CLI authentication

[jluethi]

These are some thoughts from today's Fractal call on topics for a CLI authentication refactor:

The pain-points:

• It's tricky when switching between users with the caching (2 on-disk files: .fractal.env file & the token file in the cache => create a new .fractal.env file, but the existing token is still used)
• We still require a .fractal.env file for the server IP, right? Thus, there isn't a way to do things without that env file for the time being
• Storing passwords on disk in .fractal.env files is not a good way forward. Great for testing obviously, but we should move away from it
• Not super intuitive for onboarding people that don't run their own setup scripts: When does the .fractal.env file get created? Why can't I use the command-line client from a different folder?

Goals:

1. No passwords on disk
2. Still easy to use and easy for testing

---

Some ideas:

• The fractal-demos scripts could ask interactively for username, password & IP/port (maybe with a default that we run the "production" server on) and use those on all fractal client commands afterwards.
• What's a good way to not have to type -u username -p password for every fractal client command? Some token or hashed storage, but when the user provides -u username -p password those get overwritten? In that case, only the first command in a demo script would need a -u -p, the rest would still use a (more securely) cached login.

[tcompa]

It's tricky when switching between users with the caching (2 on-disk files: .fractal.env file & the token file in the cache => create a new .fractal.env file, but the existing token is still used)

This would be fixed by #798 (comment)

We still require a .fractal.env file for the server IP, right? Thus, there isn't a way to do things without that env file for the time being

This can be easily mitigated by adding a --server-url http://example.org/fractal-backend CLI command. I also think that exposing at least one use case with no env file at all is useful. Ref #800.