* A login-time `ApproachSettlement` happens before `Location`, if
appropriate.
* Also add a future comment about FSSSignalDiscovered, for if EDDN ever adds
the schema.
It turns out some of the other strings, that do not have minLength=1 in the
schema, can be empty and that's OK. i.e. NearestDestination.
So, let's only check for the actual minLength=1 things. Which is a few
top-level key:values, and then the contents of the Traits array.
* Call it system_name in `export_journal_fssdiscoveryscan()`, as `system`
could be amigbuous.
* Might as well use `system` passed in to `journal_entry()` when calling
`export_journal_approachsettlement()`.
1. We need StarPos (as well as StarSystem)
2. Adding more state tracking in this plugin is misguided.
3. So added it in monitor instead, putting *copies* of data in the
monitor.state dictionary.
4. So we reference those, but only available in journal_entry() itself, else
we'd need to pass the whole of `state` in.
5. So instead pass in the bits of `state` only when we need them.
Also, whilst the *current* code has the 'augment files' handled last in
then if/else tree we shouldn't assume that will always be the case.
So, be paranoid and use different variables for the augment-loaded entry
and its .lower event_name.
'cos you just know one of us will trip up on it later if there's ever some
'finally' code after that conditional tree.
This is a sidestep solution to #1390. It doesn't attempt to directly
resend data, only compressing with gzip over a given size. If that STILL
returns a 413, its dropped, as without introspection of the message we
cannot make it any smaller
* Closes#1342 - A user had a NavRoute message with no Route array.
It's always from the file, so the file had to be missing it?
* This results in an EDDN '400', and now we'll drop such messages from
the replaylog so they're not constantly retried.
OK, it has `data` passed in, so this should be obvious, but let's make
it explicit both by name and in the docstring.
The docstring now also emphasies that *this* check **MUST** be used for
CAPI data, as it's dependent only on the availability of Horizons on the
account, and not on the `LoadGame` flags.
For consistency with the horizons flag. They *are* placed *from* the
`this` versions into `entry`, but we might as well go the direct route.
They have to be set explicitly here as we process the `entry` to make a
wholly new `message` rather than the `message` just being `entry` with
some changes.
