* Adds `monitor.is_live_galaxy()` for general use.
* Assumes Update 14 starts after 2022-11-29T09:00:00+00:00. That's the
currently schedule day, and recently the servers have been down by the time.
Likelihood of them coming back *up* quickly seems slim to none.
* If we couldn't parse the `gameversion` from Journal using
`semantic_version.Version.coerce()` this will fail, and assume we're on
the Legacy galaxy.
CAPI only has the Cmdr wallet value (and loan if applicable), without anything
for 'total assets'. If we send Inara setCommanderCredits without
`commanderAssets` then Inara makes a bad judgement on it and sets an
incorrect total assets value.
Also:
> Do NOT set credits/assets unless you are absolutely sure they are correct. The journals currently doesn't contain crew wage cuts, so credit gains are very probably off for most of the players. Also, please, do not send each minor credits change, as it will spam player's credits log with unusable data and they won't be most likely very happy about it. It may be good to set credits just on the session start, session end and on the big changes or in hourly intervals.
So, let's just not.
Doing so from 'Rank' means the 'Progress' event hadn't happened yet, so of
course we only ever sent all zeroes for progress.
NB: Journal-v32 doc makes *no guarantee* about the order of the events.
Is it worth trying to be paranoid about that ? For a 100% new player
everything would be "all zeroes", so we would likely need to tweak things
to store `None` as default values, and check for such.
Inara itself seems to be doing this if it has access to CAPI-sourced
Journals. If we don't send commanderAssets as part of
setCommanderCredits then it does ... something else ... and ends up with
your total assets value bouncing between what EDMC is causing and what
it sees from the CAPI-sourced journals.
So, don't send this from LoadGame any more, instead wait for Statistics,
and if it has the relevant data, also send commanderAssets.
This is old code, pre-dating the move to EDCD. We could only possibly
set the system name and address from this, and would always have already
set this from login Location event, or any jump-in event.
* If you're near a settlement on login you get an ApproachSettlement
before `monitor` has system set to pass into `journal_entry()`.
* We had a case-type of an Inara API key, so it wasn't setting the
BodyName.
* TRACE level logging of what we actually send to Inara.
