Add more capability unit tests and enable coverage reporting

[alcarney]

Description (e.g. "Related to ...", etc.)

This PR attempts to address issues around computing server capabilities raised in #377

• With these changes I'm now able to run the jedi-language-server test suite on my machine
• Thanks to the type annotation suggestions from @dimbleby, the _provider_options method is now annotated, allowing mypy to check it's usage.
• The default argument to _provide_options has been made mandatory.

Also

• I've also made an attempt at enabling test coverage - though I am not 100% sure if reporting of subprocess is working or not! :sweat_smile:
• poe will now always run all lints, even when some of them fail so that it's possible to see all failures at once.

Code review checklist (for code reviewer to complete)

• [ ] Pull request represents a single change (i.e. not fixing disparate/unrelated things in a single PR)
• [ ] Title summarizes what is changing
• [ ] Commit messages are meaningful (see this for details)
• [ ] Tests have been included and/or updated, as appropriate
• [ ] Docstrings have been included and/or updated, as appropriate
• [ ] Standalone docs have been updated accordingly

[dimbleby]

(I don't care either way about the import changes: except that that putting such things into the same commit as the actual substantial change that you are making is unhelpful for reviewers!)

I'd suggest that the default value for _provider_options() should be None rather than True: and that callers who want a True default should have to say so. It sort of doesn't matter, you will feel free to ignore me, clearly it's possible to write correct code either way. But I reckon that this is what allowed the confusion that caused the bug to be written in the first place: None is the conventional default on lots of APIs and it's natural for developers to expectt the same here.

[alcarney]

(I don't care either way about the import changes: except that that putting such things into the same commit as the actual substantial change that you are making is unhelpful for reviewers!)

Apologies! I probably should've marked this as draft before, as I wasn't necessarily expecting a review :sweat_smile:

[tombh]

I approved the PR, but @dimbleby, please chime in as well if anything stands out.

Coverage is a nice touch! Thoughts for another time: Should we set it up so that a PR is refused if coverage goes down? We could add https://coveralls.io integration for nice graphs and stuff?

[alcarney]

Should we set it up so that a PR is refused if coverage goes down? We could add https://coveralls.io/ integration for nice graphs and stuff?

Up to you.

Another option is to copy the attrs project and have the report show up in the workflow summary. It looks like it would be fairly easy to setup

[tombh]

Yeah having the summary in the workflow like that is nice. I'll see if I can add that soon.