Support --access-token parameter for CDSE

[LucHermitte]

This new option is meant to simplify 2FA on CDSE.

The issue

2FA token is extremely short lived -- it's refreshed every minute or so. This means that if we want to call eof manually several times, or to call it from a batched process, we'll need to update the 2FA token every time before calling eof.

The proposed solution

If instead we manually acquire an access token, it's lifetime will be much longer (I've haven't exactly measured how much).

This PR proposes a new option --access-token where we could feed the access token instead of login/password[/2fa-token].

Or course the access token needs to be acquired manually thanks to the procedures described on https://documentation.dataspace.copernicus.eu/APIs/Token.html

[scottstanie]

Is this redundant because the current query template has contains(Name,'{orbit_type}')? or was this a mistake to comment it out?

[LucHermitte]

IIRC, this was something I wanted to test but I didn't find/take the time to do it. So far you were using contains(Name,'{orbit_type}') and while reading the doc, I wondered whether productType eq {orbit_type} would have been enough.

I shouldn't have commited it, but forgot about it.

[scottstanie]

thanks for the improvements! only real question is about the query template change

[scottstanie]

Suggested change

	assert username and password, "Username and password values are expected!"
	if not (username and password):
	raise ValueError("Username and password values are expected!")

[LucHermitte]

I've considered username and password to be set as part of the function contract: if this precondition is not valid, then there is a programming error, and it's up to us to prevent this situation from happening.

Given username and password being set are a postcondition of get_netrc_credentials() (the function cannot return none values), which is called just before, everything is fine so far. Perfect DbC in action -- well... almost if we ignore I forgot to document the contracts in the docstring of each function, and that I should have tested for them to not be empty as well. ^^'

I usually dislike wide contracts that check every single things that are not meant to happen and throw logic errors if they do. That has a tendency to complexify source code: we add a lot of dead code that can/should never execute.

Here is the fixed code and docstring. If you really prefer wide contract instead of narrow ones. I'll throw then -- an AssertionError would still make more sense IMO.

[LucHermitte]

My mistake. The 3 scenarios weren't correctly handled. This should be better now.

[scottstanie]

thanks for the patience @LucHermitte , looks good!

[LucHermitte]

Thank you!