MNT: Refactors the code to adopt pylint

[Gui-FernandesBR]

We are going to officially adopt pylint in this repo.

Github Actions workflows erre updated:

• The black/linter bot will no longer commit to this repo
• When opening a PR, isort, black and pylint will be executed to verify if the code follows

I fixed many pylint errors, but it was a really hard task, quite time consuming. Therefore, I had to use pylint-silent to ignore some errors, those will be solved in the future, one by one.

You don't have to read all the files. Focus on the new github workflow files and the .pylintrc file

[phmbressan]

Good work. I left some suggestions, I am not an expert on linters, so take those with a grain of salt: but I do think some of the defined linting rules are not strict enough.

This already has produced improvements and more idiomatic code and has potential to accelerate our reviews.

For the long term, let's keep in mind always that linters are good to suggest improvements, but they do not force you to anything, there are edge cases.

[phmbressan]

30? That seems a bit too high, my suggestion would be 15 which is already quite a lot.

[phmbressan]

I guess we might have some methods that surpass the default here, but I don't think raising the limit too much makes sense.

Surpassing the default should be an advise to refactor. I know this is not the purpose of this PR, but disabling the issue in the problematic methods would likely do more to remind us on refactors than putting the value too high (in my opinion).

[phmbressan]

The same comment I made earlier on setting the limits too high.

I don't know which method right now approaches 50 returns, but that is too much. I do think that the default is too low, though.

Also, it makes sense if this value stays close to the max_branch (which it is right now). My suggestion would be like 21.