v0.7.0

• BREAKING CHANGE: A new request option, maxRetriesSeconds, limits the total duration of retried requests, replacing the previous
  maxRetries option that limited the number of retried requests. It defaults to 65 seconds, which should be enough to cover a typical
  brief read-only period on Wikimedia wikis. Interactive applications may wish to use a lower value, to show an error to users earlier rather than waiting for a long time. The previous maxRetries option should no longer be used.
• m3api can now automatically add token parameters to requests, controlled by the two new request options tokenType and tokenName. The most common case, e.g. for action=edit, is to use tokenType: 'csrf' with the default tokenName ('token'). m3api will automatically fetch and cache the token (and this internal request can be automatically combined with other action=query requests), discarding stale tokens and retrying upon encountering a badtoken error. Tokens are cached in the public Session.tokens Map, which users and extension packages are encouraged to clear() after changing the session state (e.g. login), to avoid the overhead of a badtoken error. (Note that the m3api-botpassword extension package does this for you.)
• The public interface of m3api has been clarified. Most importantly, Session.defaultParams, Session.defaultOptions and DEFAULT_OPTIONS have been declared public, and extension packages are encouraged to use the latter two for their own options as well. Guidelines for extension packages have also been added to the README.
• Requests that produced maxlag or readonly errors are now automatically retried, even if the response did not include a Retry-After response header. (Currently, MediaWiki only sends this header for maxlag errors.) Two new request options, retryAfterMaxlagSeconds and retryAfterReadonlySeconds, control the default retry delay (in seconds) for these errors. The defaults of 5 and 30 seconds respectively are intended to be useful for Wikimedia wikis. If you increase these values, don’t forget to increase maxRetriesSeconds as well.
• The Node.js backend (specifically axios.js) now keeps the network connection alive (using Node’s default Keep-Alive settings), which can speed up consecutive API requests (e.g. to get and then use a token). Requests with technically different options can be combined in some more situations. Specifically, a request explicitly specifying a default option is compatible with one not specifying the option at all (both will use the default), and the dropTruncatedResultWarning option does not affect compatibility at all (the option is handled while combining requests, so that truncated result warnings are only sent to the correct requests).
• Updated dependencies.