This was wrong since 291fbf2908e0f7419769a7727ee0a79cf58a9342 due to the
check saying "only active if in CQC", when it needed to be "only active
NOT in CQC, along with these other conditions".
* Session.profile() was unused (used to be called from stats.py, but
that uses cached data now).
* Session.query() was unused, other than by itself. Normal calls will
currently be via companion.Session.station(). Future CAPI queries
like `/fleetcarrier` might add their own companion.Session function.
* And in doing so get --capi-pretend-down working again.
* Small tweak to EDMarketConnector to not throw extra exception if there
was a CAPI query exception.
NB: We can't use a generator here to make a python object of the data,
to then use json.dumps() on because the raw_data is a *string* (decoded
from what we received from the CAPI service), and thus it will get
encoded as such, i.e.
"raw_data": "{\"id\":322...
when we want:
"raw_data": {"id":322...
We do not want to json.loads() that string only to then json.dumps() it
because the whole point is that this is the **raw** data to help
diagnose any issues with the CAPI service/data. Such a conversion and
back could either throw an exception we don't want here (because we want
the raw data) or possibly distort things from what was actually
received.
* If we don't invalidate then the companion.Auth code will do nothing
due to "already auth'd".
* We need to give the auth flow time to complete, so need to return.
* As that auth flow can take indeterminate time, not setting a timed
retry of the CAPI query here. We should consider setting a flag and
reacting in the Auth code though.
I keep observing it take 3-4s to update the UI after a manual CAPI
request. This showed up as mostly *in*
AppWindow.capi_handle_response(), but the moment I ran it under PyCharm
profile that went down to 400ms.
* The 'EDMC' prefix on all these classes is to make it clear they're for
internal passing around of requests/responses, rather than holding the
literal raw CAPI request and response.
* The request and response queues are now commented, including the
detail that the response queue is created by the caller and then set
'here' by Session.set_capi_response_queue().
This should have been set from the latest Journal file, and the
key/value is in LoadGame in Odyssey. It's only documented as:
"Whether the sending Cmdr has an Odyssey expansion."
in the current EDDN Journal schema. Thus sending this as False if the
Cmdr last logged into Horizons/base game should be OK.
* It's no use `dict(CAPIData)` if that contains other `CAPIData`. So,
rather than write something to do that recursively just implement a
simple JSON Encoder class and specify its use.
