* 'type: ignore' some ctypes operations on variables.
* Use `c_long(<value>)` on some returns. The ctypes types do work that way
as constructors.
* Fix the BAseHTTPHandler.log_request() types to match superclass.
* flake8 6.0.0 dropped support for, the broken, --diff.
* We want to only run against python files. We will have 'git diff's for
other types of files.
* Uses 'git diff -z', 'grep -z -Z' and 'xargs -0' so as to pass NUL-terminated
strings around to avoid "special characters in path/filenames" issues.
* Typed `master` to each `__init__()`.
* Having to `# type: ignore` the base class for the classes which are
"tk on darwin, else ttk" as this 'dynamic' type confuses mypy.
See the comment on `class Frame` for a suggested proper fix, which will
be more work.
* This did, however, remind me that the `data` passed into `cmdr_data()`
is an amalgam of `/profile`, `/market` and `/shipyard` queries.
This means that the data.source_endpoint is **not correct for all of
the data and its use**. As such I had to pass 'hard coded' values into
the function from the various CAPI export functions. They know what it
is they're exporting.
* As this reminded me that "CAPI `data` is actually a `CAPIDATA`", I've
documented that in PLUGINS.md, but with a dire warning against relying on
any of the extra properties.
* This is *temporary* pending properly implementing utilising the Legacy
CAPI host.
* Check in the EDMarketConnector.EDApp.capi_request_data() function *and*
also in some companion.session functions. But not absolutely all possible
entry points because we'll be undoing it when we implement Legacy support.
This *is* sufficient for the current core code entry points. If any plugin
is invoking its own CAPI requests, well it shouldn't be.
It's actually just the NAMES that got changed as part of the EDDN rework, so
this would have made no difference to the tests. But now a grep won't find
any instance of the old names.
* In theory we would always see `Fileheader` and clear `pending[]`, but let's
be extra paranoid and also clear it if there's a gameversion/build difference
between the prior event and the current one.
1. Due to the _TIMEOUT on the actual `post()` of a message it would be
possible for new entries to get queued in the meantime. These queued
entries could be 'in session' and end up going through pending and thus
sent before one of the 'new session' events is detected so as to clear
pending. The `this.gameversion/build` could have changed in the meantime,
so are no longer correct if game client changed.
2. So, pass in the current gameversion/build when a message is pushed into
the queue, and parse those back out when they're pulled out of the queue.
3. Use those versions in the message, not `this.` versions.
* Record the 'state' version of these in `this`.
* Use those when constructing the message.
* NB: Need to check if messages can be retained in the queue across client
changes. Coming up ....
* I'd missed 'Plugin ' off 'Plugin Developers'.
* Clarification added that EDDN messages will still go through quickly if
not delayed by user settings or an EDDN Gateway issue.
