Ignore warnings when rendering rst

[ishirav]

What's the problem this feature will solve?
It is very easy to come across packages in Warehouse which have rst descriptions that are wrongfully rendered as plain text. I believe the reason for this is the strictness of the readme_renderer - any warnings emitted by the rst renderer cause failure.

Describe the solution you'd like
My very simple suggestion is to change the halt_level in rst.py from 2 to 3. This would result in ignoring warnings, and halting only when encountering more severe errors.

After trying this change on a few random examples of READMEs that currently don't get rendered, I'm convinced that this change does not cause any problems, and that it's perfectly safe to ignore warnings. The resulting HTML is way better, nicer and more readable than just displaying the README as plain-text.

The only possible downside is that some actual plain-text READMEs might get rendered as if they were rst. I don't think that would be a serious problem - rendering text to rst might add some formatting or change line wrapping, but probably won't mangle the text beyond recognition or make information disappear.

Note that when running python setup.py check -r -s to check a package, it would be beneficial to still show any warnings and not ignore them.

Additional context
Some random examples of packages with rst descriptions that are rendered as plain text (they are very easy to come across):

• https://pypi.org/project/django-domain-specific-language/
• https://pypi.org/project/django-503/#description
• https://pypi.org/project/popit-django/#description

[theacodes]

I am generally in favor of this, but definitely need @di to agree to it as well.

[dstufft]

FWIW the reason it's strict now is just because that's been the behavior forever, so when I extracted this from PyPI, I just kept the same settings. That's not to say that it can't change of course! Just that basically the rationale is probably lost to the sands of time at this point, and I think it's perfectly fine to change it.

[di]

The one thing I'm concerned with here is what this will look like for projects that have intentionally plaintext descriptions (but are from a time before Description-Content-Type).

Thus, this may depend on something like the suggestion at pypi/warehouse#4002.