Adarnauth-esi

This release prevents any token refresh logic from being run if new=True is passed to the decorator.

Certain operations rely on GET requests with url parameters which are not appended to the URL until after the key is generated, resulting in key collisions. Key generation is now the hash of method, url, params, and payload.

allianceauth/allianceauth877

An additional convenience method is also included: [`esi.clients.minimize_spec`](https://github.com/Adarnof/adarnauth-esi/blob/v1.14.1/esi/clients.pyL218), which accepts a swagger spec dict, list of resources, and list of operations to keep. This removes all defninitions from the spec dict which are not tagged as a desired resource and are not a desired operation name. This is useful to reduce bloat when shipping a swagger spec with your app.

I haven't updated the scope list since the initial release - there are plenty out there that don't get automatically creasted in migrations. If a scopes was unrecognized (such as the first time seeing one of these new scopes) then it would be excluded from the list of scopes used to filter tokens. This is obviously incorrect behaviour - if we don't have the scope on file how can we have tokens with it? This update corrects this behaviour and fixes an issue with filtering for no scopes.

Turns out the length of access tokens and refresh tokens isn't static: it depends on a whole bunch of things, one of which is number of scopes. Now that it's possible to request up to 60 scopes per token, people are receiving refresh tokens longer than 254 characters which gets truncated when saved. This alters the character field to a text field which has no length limits.

https://code.djangoproject.com/ticket/18378

This update changes how `require_scopes_exact` handles filtering: it explicitly selects `pk` and `scopes__id` so that the `scope_id` column ends up in the select statement, which avoids an SQL bug where it doesn't recognize the column in the having clause when used in a `Q` filter.

When a field is passed a list of models, it coerces them into database values by collecting their primary keys. In v1.4.8 I changed the scope query to search by scope name, so when looking for integers it found no scopes. This lead to the deduplication method incorrectly identifying the first token with the same number of scopes for a given character as equivalent as it did not have the actual scope models to filter by, replacing it with the newly created token.