setup: use old importlib_metadata version to fix kombu failing on python < 3.8

Many libraries use the importlib_metadata library as fallback when running on
Python versions older than 3.8 . For example setuptools when easy_install is
used for install the Kallithea console_scripts entrypoints in the bin folder.
The dependencies on importlib_metadata were indirect and without constrains on
version number.

The problem is that Celery uses Kombu, which (on Python < 3.8) uses
importlib_metadata in a way that is incompatible with importlib_metadata > 5.

Most obvious, building docs failed as:
Running Sphinx v5.1.1

Configuration error:
There is a programmable error in your configuration file:

Traceback (most recent call last):
File ".../kallithea/venv/lib64/python3.7/site-packages/sphinx/config.py", line 347, in eval_config_file
exec(code, namespace)
File ".../kallithea/docs/conf.py", line 17, in <module>
import kallithea
File ".../kallithea/kallithea/__init__.py", line 45, in <module>
CELERY_APP = celery.Celery() # needed at import time but is lazy and can be configured later
File ".../kallithea/venv/lib64/python3.7/site-packages/celery/local.py", line 492, in __getattr__
[name])
File ".../kallithea/venv/lib64/python3.7/site-packages/celery/app/__init__.py", line 2, in <module>
from celery import _state
File ".../kallithea/venv/lib64/python3.7/site-packages/celery/_state.py", line 15, in <module>
from celery.utils.threads import LocalStack
File ".../kallithea/venv/lib64/python3.7/site-packages/celery/utils/__init__.py", line 16, in <module>
from .nodenames import nodename, nodesplit, worker_direct
File ".../kallithea/venv/lib64/python3.7/site-packages/celery/utils/nodenames.py", line 6, in <module>
from kombu.entity import Exchange, Queue
File ".../kallithea/venv/lib64/python3.7/site-packages/kombu/entity.py", line 7, in <module>
from .serialization import prepare_accept_content
File ".../kallithea/venv/lib64/python3.7/site-packages/kombu/serialization.py", line 440, in <module>
for ep, args in entrypoints('kombu.serializers'): # pragma: no cover
File ".../kallithea/venv/lib64/python3.7/site-packages/kombu/utils/compat.py", line 82, in entrypoints
for ep in importlib_metadata.entry_points().get(namespace, [])
AttributeError: 'EntryPoints' object has no attribute 'get'

That made readthedocs builds fail, when it in the default web configuration
used Python 3.7 .

Fixed by introducing an explicit dependency on importlib_metadata < 5.

setup: support Bleach 4.2 for Python 3.10 support

Changelog shows no significant API changes.

Bleach 3.2 and later are however even more unreasonably paranoid than 3.1, and the test
thus has to be updated and we stop supporting 3.1 .

setup: support FormEncode 2.0.0 for Python 3.10 support

Changelog shows no problematic changes.

setup: make chardet a mandatory dependency

It was made mandatory in 9685f50a69d0. At that time it seemed like it always
were present due to indirect dependencies, but apparently that is no longer the
case.

hg: support Mercurial 5.8

Some 'remote:' messages changed to appear on stderr.

celery: upgrade to Celery 5.0 ... and adjust for Click API

Celery 5 has apparently no relevant API or config changes.

Celery is however switching to click. run_from_argv goes away, and there is no
simple way to do as before and start the worker with our Celery app but still
use Celery's own command line parser.

Apply hacks to make sure it still is possible to run like:

kallithea-cli celery-run -c my.ini -- --help

kallithea-cli celery-run -c my.ini -- --loglevel=ERROR broker_url=amqp://u:p@localhost:5672/v

imports: try to use global imports unless it is a layering violation

To minimize the impact, do imports that violate the layering at runtime instead
of at import time.

mercurial: support Mercurial 5.5

No release notes yet, but testing shows it working with a few changes.

A few tests need updating because error messages from remote ssh like our
sys.stderr.write('abort: %s\n' % error)
like for
remote: abort: Access to %r denied
will now appear on stderr instead of stdout - a very reasonable bug fix.

setup: bump version numbers to current max

Based on 'pip freeze' before/after:

sed -i -e '/>=[^#]*$/s/, < [0-9.]\+//g' -e 's, == , >= ,g' setup.py dev_requirements.txt

Markdown 3.3 is a few months old could be bumped too ... but it change test
output due to
https://python-markdown.github.io/change_log/release-3.2/#codehilite-now-always-wraps-with-ltcodegt-tags
and can wait.

This is landing early in the development phase and will thus get good test
coverage.

setup: exclude celery 4.4.4 which is broken due to unexpressed dependency

Celery 4.4.4 introduced the use of the 'future' package but forgot to
express it in its dependencies.

We could add the missing dependency on 'future' in Kallithea, but since the
problem is already fixed upstream shortly after 4.4.4 was released [1], we can
be sure that the next release (presumably 4.4.5) will contain the fix.

[1] https://github.com/celery/celery/pull/6146

cleanup: drop last traces of kallithea-config

The kallithea-config sources were removed in commit
213085032127e941a3bd93d0e510828a9d87bf32 but an entry point was still
created by setup.py.
Moreover, the ini file still referenced this, instead of kallithea-cli
(config-create).

hg: support Mercurial 5.4

rc0 has no release notes yet, but it seems to work and the test suite pass ...

setup: install pip in virtualenv to make sure we have the latest version

Older versions are good enough for bootstrapping (and might also be good for
everything else) but gives:

WARNING: You are using pip version 19.3.1; however, version 20.0.2 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

The user might still get this warning initially, but then it goes away ...

setup: avoid bleach 3.1.4 for now - it seems to deliberately cause regressions

See https://github.com/mozilla/bleach/blob/master/CHANGES and
https://github.com/mozilla/bleach/commit/d6018f2539d271963c3e7f54f36ef11900363c69
... which adds xfails for use cases similar to how we use bleach.

It would completely remove style attributes instead of dropping bad parts of
them, as shown by the markup_renderer.py doctest it made fail:

>>> MarkupRenderer.render('''<img id="a" style="margin-top:-1000px;color:red" src="http://example.com/test.jpg">''&apos;, '.md')
Expected:
'<p><img id="a" src="http://example.com/test.jpg"; style="color: red;"></p>'
Got:
'<p><img id="a" src="http://example.com/test.jpg"; style=""></p>'

Until a better solution is found, stick to 3.1.3 and accept the potential
ReDoS.

auth: also use safe password hashing on Windows using bcrypt

For unknown reasons, Kallithea used different hashing algorithms on Windows and
Posix. Perhaps because problems with bcrypt on Windows in the past. That should
no longer be an issue, and it doesn't make sense to have different security
properties on the platforms.

While changing to bcrypt everywhere, also remain backwards compatible and
accept existing passwords hashed with sha256 - both on Windows (where it used
to be used), and elsewhere (in case a system has been migrated from Windows to
Unix).

cleanup: minimize use of lambda expressions - we have 'def' for that purpose

Fix some flake8 warnings "E731 do not assign a lambda expression, use a def".

celery: upgrade to Celery 4

Celery 3 doesn't support Python 3.7 or later. This upgrade is thus essential
for full Python 3 support. But note that
https://docs.celeryproject.org/en/4.4.0/faq.html#does-celery-support-windows
says "No".

The names of config settings changed in Celery 3 to 4, as described on
https://docs.celeryproject.org/en/3.0/whatsnew-4.0.html#lowercase-setting-names .

Celery 4 config settings can now be specified in Kallithea .ini files by prefixing
with `celery.` - for example as `celery.broker_url`.

Remain backwards compatible for the usual settings, and map old names to the
new names.

setup: bump version numbers to current max

This will most likely give best py3 support, and we need thorough testing
anyway.

Based on 'pip freeze' before/after:

sed -i '/>=[^#]*$/s/, < [0-9.]\+//g' setup.py dev_requirements.txt

py3: officially support Python 3

All tests pass and no known regressions.

py3: switch to use Python 3 interpreter, temporarily leaving many things very broken until they have been migrated/fixed in a reviewable way

Bump Mercurial minimum version to 5.2 - the first version that claim stable py3
support.

setup: support Mercurial 5.3

Kallithea has been updated for the only known API change in 5.3.

The 5.3 upgrade notes do not indicate other relevant changes.

setup: bump sqlalchemy minimum version to 1.2.9 to get rid of py3 warning

Avoid verbose warning:

build/minimum-dependency-versions-venv/lib/python3.7/site-packages/sqlalchemy/util/langhelpers.py:637
.../site-packages/sqlalchemy/util/langhelpers.py:637: DeprecationWarning: `formatargspec` is deprecated since Python 3.5. Use `signature` and the `Signature` object directly
d_args = inspect.formatargspec(spec[0][1:])

setup: bump alembic minimum version to 1.0.10 to get rid of py3 warning

Avoid verbose warning:

.../site-packages/alembic/util/langhelpers.py:92: DeprecationWarning: `formatargspec` is deprecated since Python 3.5. Use `signature` and the `Signature` object directly
formatvalue=lambda x: '=' + x)

setup: bump decorator minimum version to 4.2.1 to get rid of py3 warning

Avoid verbose warning:

.../site-packages/decorator.py:95: DeprecationWarning: `formatargspec` is deprecated since Python 3.5. Use `signature` and the `Signature` object directly
formatvalue=lambda val: "", *argspec)[1:-1]

setup: bump dulwich minimum version to 0.19.0 to get good py3 support

Fix failure in test_compare_forks_on_branch_extra_commits_git ... but make a
major bump to make sure we get good py3 support in this cruicial and complex
low level library.

setup: bump whoosh minimum version to 2.7.1 to get py3 support

Fix:

- kallithea/tests/functional/test_search_indexing.py:111 TestSearchControllerIndexing.test_repository_tokenization[content-this_should_be_unique_content-1-group/*]

File ".../lib/python3.7/site-packages/whoosh/reading.py", line 241, in expand_prefix
if fn != fieldname or not text.startswith(prefix):
TypeError: startswith first arg must be bytes or a tuple of bytes, not str

setup: bump mako minimum version to 0.9.1 to get py3 support

Avoid test_api_get_pullrequest crash:

data/env3/lib/python3.7/site-packages/mako/template.py:653: in _compile_text
code = compile(source, cid, 'exec')
E File "email_templates_button_html", line 15
E def render_body(context,url,title='',padding_top=,padding_bottom=,**pageargs):
E ^
E SyntaxError: invalid syntax

setup: bump python-dateutil minimum version to 2.1.0 to get py3 support

Avoid py2 syntax:

E File "/home/mk/kallithea-py3/build/minimum-dependency-versions-venv/lib/python3.7/site-packages/dateutil/tz.py", line 78
E `self._name`,
E ^
E SyntaxError: invalid syntax

setup: bump beaker minimum version to 1.10.1 to get py3 support

1.10.0 failed on py3 because it was using the reserved async keyword:

File ".../build/minimum-dependency-versions-venv/lib/python3.7/site-packages/beaker/synchronization.py", line 289
self.async = 0
^
SyntaxError: invalid syntax

setup: bump formencode minimum version to 1.3.1 to get py3 support

1.3.0 failed with py3:

build/minimum-dependency-versions-venv/lib/python3.7/site-packages/formencode/api.py:153:
if unicode is not str: # Python 2
E NameError: name 'unicode' is not defined

setup: bump ipaddr minium version to 2.2.0 to get py3 support

2.2.0 is also the latest version, but released in 2017.

Previous versions failed installation on py3 with:

File "/tmp/pip-install-o31ka351/ipaddr/ipaddr.py", line 1450
ip_int = 0L
^
SyntaxError: invalid syntax
----------------------------------------

setup: bump TurboGears minimum version to 2.4

Avoid failures starting with test_api_wrong_key:

E File ".../build/minimum-dependency-versions-venv/lib/python3.7/site-packages/tg/request_local.py", line 37, in languages_best_match
E items = [i for i, q in sorted(al._parsed, key=lambda iq: -iq[1])]
E TypeError: 'NoneType' object is not iterable

setup: bump WebOb minimum version to 1.8

b075693b3214 introduced use of acceptable_offers which with WebOb < 1.8 would
fail with:

File ".../kallithea/lib/middleware/pygrack.py", line 189, in __call__
elif req.accept.acceptable_offers(self.valid_accepts):
AttributeError: 'MIMEAccept' object has no attribute 'acceptable_offers'

py3: open files as binary or not, depending on how we want to use them

The difference will matter when bytes and str are different.

hg: bump minimum version to 5.1

We will soon move to Python 3 which only will support 5.1 or later.

Remove old hacks and tech debt.

Also avoids future warning:
DeprecationWarning: inspect.getargspec() is deprecated since Python 3.0, use inspect.signature() or inspect.getfullargspec()

page: minimal change to move from webhelpers.paginate to paginate

webhelpers is dead and doesn't work with py3. paginate is not very actively
maintained, but it is the natural successor to webhelpers.paginate, it seems
stable, and it works with py3.

This is a minimal change that seems to work. It preserves existing tech debt
... and adds a little bit more. It will be cleaned up next.

webhelpers.paginate had built-in SqlAlchemy support - now we have to handle it
explicitly.

setup: set explicit minimum version for all dependencies

Kind of arbitrarily chosen, but it seems like reasonable not-too-recent
versions that still provide a consistent baseline.

setup.py: bump Pygments minimum version to 2.2.0

With pygments < 2.2.0, the markup_renderer doctest fails:

> python -m doctest kallithea/lib/markup_renderer.py
**********************************************************************
File "kallithea/lib/markup_renderer.py", line 184, in markup_renderer.MarkupRenderer.markdown
Failed example:
print MarkupRenderer.markdown('''
#!/bin/bash
echo "hello"
''')
Expected:
<table class="code-highlighttable"><tr><td class="linenos"><div class="linenodiv"><pre>1
2</pre></div></td><td class="code"><div class="code-highlight"><pre><span></span><span class="ch">#!/bin/bash</span>
<span class="nb">echo</span> <span class="s2">&quot;hello&quot;</span>
</pre></div>
</td></tr></table>
Got:
<table class="code-highlighttable"><tr><td class="linenos"><div class="linenodiv"><pre>1
2</pre></div></td><td class="code"><div class="code-highlight"><pre><span class="ch">#!/bin/bash</span>
<span class="nb">echo</span> <span class="s2">&quot;hello&quot;</span>
</pre></div>
</td></tr></table>
**********************************************************************


To avoid having to manage multiple outputs from multiple versions, just bump
the lower version.

pygments 2.2.0 was released on Jan 22, 2017.

hg: support Mercurial 5.2

Automated and manual testing shows no problems with mercurial-5.2rc0 , and
draft release notes also raise no concerns.

setup: TurboGears 2.4 (and WebOb 1.8.0)

All the known problems blocking an upgrade has been fixed.

setup: support Mercurial 5.1

Testing and release notes doesn't indicate any changes that influence use with
Kallithea.

helpers: use WebHelpers2 as much as possible - it supports Python3, and WebHelpers is dead

The remaining uses of WebHelpers have to be replaced too - see
https://webhelpers2.readthedocs.io/en/latest/migrate.html .

setup: bump formencode minimum version to 1.3.0

The formencode version range included both 1.2.x and 1.3.x releases.
However, since 1.3.0, _to_python and validate_python are deprecated and
renamed to _convert_to_python and _validate_python, respectively.

With current pytest, these (long) deprecation warnings are shown in the test
logs.

There are two options:
- restrict maximum version to 1.2.x
- bump minimum version to 1.3.x

In this commit we choose the latter approach, going towards the future
rather than the past.

setup: bump some setup.py dependency versions

Upgrade notes for these libraries have not been investigated thoroughly, but
testing seems to show that it works. We are also early in the development
phase, so big problems will be caught by general testing before going wide.

Note: TurboGears2 is not upgraded to 2.4 yet. That upgrade would require us to
first move away from using the Pylons compatibility layer.

setup: support Mercurial 5.0

Some API changes has already been handled.

setup: drop support for Python 2.6

It would be a a stepping stone for the migration to Python 3 to only support
Python 2.7. Even though we don't make any big changes now, it might allow us to
remove some workarounds or use some new forward-compatible features.

Mercurial dropped support for Python 2.6 2 years ago.

setup: restrict TurboGears2 version to 2.3.x

In TurboGears2 2.3.12, the latest version in the 2.3.x range, the WebOb
dependency requirement is [1]
WebOb >= 1.2, < 1.8.0

In TurboGears2 2.4.0 (which is in pre-release state at the time of this
commit), this becomes [2]:
WebOb >= 1.8.0, < 1.10.0

In the Kallithea dependency list, we have matched our WebOb version
requirements to that of TurboGears2 and use:
WebOb >= 1.7, < 1.8

while our TurboGears2 requirement was liberal and accepted anything in the
2.x range:
TurboGears2 >= 2.3.10, < 3

To avoid new Kallithea installations failing with conflicting WebOb version
requirements after TurboGears2 2.4.0 is released, restrict the version of
TurboGears2 to 2.3.x on the stable branch.

For the default branch, the update to TurboGears2 2.4.0 can be considered
once it's released.

[1] https://github.com/TurboGears/tg2/blob/tg2.3.12/setup.py#L54
[2] https://github.com/TurboGears/tg2/blob/ed89788c3f5dab5a182a938543c9ee4ec14dd7ef/setup.py#L41

dependencies: bump minimum requirements to fix installation with minimum versions

When manually setting all dependency requirements to the minimum version in
setup.py, as follows:

sed -i 's/>=/==/' setup.py dev_requirements.txt

and running:

pip install --upgrade -e . -r dev_requirements.txt python-ldap python-pam

following warnings were given:

sphinx 1.7.9 has requirement babel!=2.0,>=1.3, but you'll have babel 0.9.6 which is incompatible.
sphinx 1.7.9 has requirement docutils>=0.11, but you'll have docutils 0.8.1 which is incompatible.
sphinx 1.7.9 has requirement Pygments>=2.0, but you'll have pygments 1.5 which is incompatible.

Fix these by bumping the minimum versions of these dependencies.

hg: support Mercurial 4.9

Manual testing confirms it works, the test suite pass, and the Mercurial
release notes doesn't show anything that raise any concerns.

setup.py: support Paste 3.0.x

In a fresh virtualenv on the stable branch, pastescript 3.0.0 is installed
which depends on paste 3.0.x. Using this virtualenv to upgrade to the
default branch, using 'pip install --upgrade -e .' fails because on the
default branch, the paste version is restricted with '>= 2.0.3, < 3'.
Following error occurs:

pastescript 3.0.0 has requirement Paste>=3.0, but you'll have paste 2.0.3 which is incompatible.
...
Traceback (most recent call last):
File "<string>", line 1, in <module>
File ".../kallithea/kallithea-release/setup.py", line 160, in <module>
""",
File "/usr/lib64/python2.7/distutils/core.py", line 151, in setup
dist.run_commands()
File "/usr/lib64/python2.7/distutils/dist.py", line 953, in run_commands
self.run_command(cmd)
File "/usr/lib64/python2.7/distutils/dist.py", line 972, in run_command
cmd_obj.run()
File ".../kallithea/venv/kallithea-release/lib/python2.7/site-packages/setuptools/command/develop.py", line 36, in run
self.install_for_development()
File ".../kallithea/venv/kallithea-release/lib/python2.7/site-packages/setuptools/command/develop.py", line 117, in install_for_development
self.run_command('egg_info')
File "/usr/lib64/python2.7/distutils/cmd.py", line 326, in run_command
self.distribution.run_command(command)
File "/usr/lib64/python2.7/distutils/dist.py", line 972, in run_command
cmd_obj.run()
File ".../kallithea/venv/kallithea-release/lib/python2.7/site-packages/setuptools/command/egg_info.py", line 270, in run
ep.require(installer=installer)
File ".../kallithea/venv/kallithea-release/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2307, in require
items = working_set.resolve(reqs, env, installer)
File ".../kallithea/venv/kallithea-release/lib/python2.7/site-packages/pkg_resources/__init__.py", line 854, in resolve
raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.VersionConflict: (Paste 2.0.3 (.../kallithea/venv/kallithea-release/lib/python2.7/site-packages), Requirement.parse('Paste>=3.0'))


The '< 3' restriction is introduced with commit
e1ab826131334150b1f003e26de3207c34fc6e67 in January 2017, at which point
2.0.3 was the latest version. Version 3.0.0 was introduced in October 2018.

Paste has a new maintainer and moved to github, after years of
inactivity (March 2016 -> Oct 2018). There have AFAICS not been
incompatible changes. This analysis is based on:
- the news file: https://pythonpaste.readthedocs.io/en/latest/news.html
- the commit message of the 3.0.0 release:
(https://github.com/cdent/paste/commit/9ceef07267ba83ea5c00533f85f9edf9ba38cd71)

"This is for the sake of getting something out there, including
fixes to get stuff working with Python 3.7."

- and a walk through the commits since 2.0.3 on github
(https://github.com/cdent/paste/commits/master).

gearbox: drop last traces of upgrade-db paster command

Everything has changed anyway.

cli: convert 'gearbox celeryd' into 'kallithea-cli celery-run'

Note:
- '--' is never explicitly present in the arguments when using Click.
The click parser will take care of '--' as separator between
dash-dash-arguments and positional arguments, following standard UNIX
conventions.

cli: convert 'gearbox make-rcext' in 'kallithea-cli extensions-create'

Note: 'extensions' instead of 'rcextensions' as first step to get away from
the 'rc' prefix.

cli: convert 'gearbox cleanup-repos' into 'kallithea-cli repo-purge-deleted'

Some changes to user-facing text are done.

cli: convert 'gearbox update-repoinfo' into 'kallithea-cli repo-update-metadata'

The --update-only option is replaced by listing repository names as separate command line arguments.

The --invalidate-cache option is dropped and we just always invalidate all caches.

cli: convert 'gearbox make-config' into 'kallithea-cli config-create'

... and update documentation.

cli: initial introduction of 'kallithea-cli' command

This commit adds a command 'kallithea-cli' that intends to replace the
existing set of 'gearbox' commands that relate to setting up kallithea.
Gearbox would still be used for 'gearbox serve', but other commands like
'make-config', 'setup-db', etc. would be converted to 'kallithea-cli'
commands.

The python package 'Click' is used to generate the CLI. Using decorators,
this package makes it very easy to generate a CLI out of simple methods.
See: http://click.pocoo.org/7/

Using Gearbox for custom commands is possible, but documentation on this
topic is limited. As the added value of Gearbox for that use case is not
clear, we can well switch to something else if it seems better/easier.

lib: use bleach to sanitize HTML generated from markdown - fix XSS issue when repo front page shows README.md

Reported by Bob Hogg <wombat@rwhogg.site> .

setup: bump all upper pip dependency versions to minor updates of what currently is available and testable on pypi

Based on manual editing after:
pip freeze | sed -n 's/==/ /gp' | while read p v; do sed -i -e "/\<$p[ \"]/s/\(\",\|$\)/, < $v\1/gi" setup.py dev_requirements.txt; done

These updates have been tested with automated tests and some amount of manual
testing. Remaining problems will hopefully be caught by additional testing
before the branch is declared stable.

setup: clarify that we require Routes less than 2.0

The next version after 1.13 is currently 2.0 and breaks test_files.py
test_file_annotation and test_file_annotation_git .

celery: clarify that celery 4 doesn't work

The latest supported Celery version, 3.1.26.post2, is the latest in the whole 3
series. It works fine. But celery-4.0.0 doesn't work at all when testing. For
now, just make it explicit that this is the limit.

setup: sort gearbox.commands

There did not seem to be any particular order, so alphabetical sorting seems
most appropriate.

setup: normalize casing of dependencies and formatting of constraints

The package name casing might seem random, but it is more correct than our own random casing.

These changes mainly come from:
pip freeze | sed -n '/==/s/==.*//gp' | while read a; do sed -i "s/$a/$a/i" setup.py dev_requirements.txt ; done
sed -i -e 's/>=/ >= /' -e 's/ >=/ >=/' -e 's/>= />= /g' -e 's/,</, </' -e 's/</< /' -e 's/< /< /g' -e 's/< =/<= /g' setup.py dev_requirements.txt

hg: bump minimum version to 4.1.1

522cfb2be9e1 introduced test_custom_hooks_preoutgoing, but thorough testing now
reveals that the test failed with Mercurial 4.0 to 4.1.0 . Instead of
investigating and fixing code or test, just accept this more than one year old
version as minimum.

setup: support Mercurial 4.6

A number of issues were found but have been fixed.

setup: support Mercurial 4.5.x

This requires passing an extra parameter to memctx __init__ after
https://www.mercurial-scm.org/repo/hg/rev/8a0cac20a1ad .

setup: drop support for Mercurial < 4.0

There is little point in supporting Mercurial versions more than 2 years old.

Also, the old memfilectx hack gets in the way for a clean workaround for a new
API change.

Some further cleanups might be possible when we can assume Mercurial >= 4.0 .

setup: do like TurboGears2 and don't support WebOb 1.8

TurboGears2 2.3.12 has been released and made it clear they don't support WebOb
< 1.8.0 - https://github.com/TurboGears/tg2/commit/1aee68f1239c76cabe945aa50ca1f7e7afea6842 .

A plain "pip install -e ." would obey the Kallithea setup.py and install WebOb
1.8.0, but fail at runtime with:
(WebOb 1.8.0, Requirement.parse('WebOb<1.8.0,>=1.2'), set(['TurboGears2']))

setup: updated dependencies to accept latest Pylons release (1.0.3).

A couple of weeks ago the Pylons project has released version 1.0.3, removing
the previously stable version 1.0.2 in the process. In turn, this would mean
that new installation of Kallithea will end-up with older version of Pylons
than what is actually available, and in particular a much older release than
1.0.2.

tests: git changeset authors need to have the format 'username <user@example.com>'

New verions of dulwich caused tests like test_compare_forks_on_branch_extra_commits_git
to fail because of this.
Since this is fixed now, re-allow dulwich versions 0.18.6 and newer.

setup: temporary workaround to avoid dulwich 0.8.16 - it cause test failures

i.e. test_compare_forks_on_branch_extra_commits_git
Note: might be In Memory Changeset related

vcs: support Mercurial 4.4

Review and testing shows no further problems.

setup: don't use setuptools 34 - it has indirect conflicts with the celery version supported on the stable branch (Issue #266)

Setuptools==34 requires packaging>=16.8 which has an unconstrained requirement
of pyparsing ... but actually it doesn't work with pyparsing==1.5.7 ... which
is required by celery<2.3 ... which this version of Kallithea requires.

Celery has been upgraded on the development branch but we don't want to do that
on the stable branch.

db: upgrade to SQLAlchemy 1.1, fixing invalid PostgreSQL SQL in User.is_default_user

eea19c23b741 triggered a bug in SQLAlchemy 1.0.17, causing invalid SQL to be
emitted for PostgreSQL: For the (Python) query '(x == y) == z', SQLAlchemy
generates the SQL 'x = y = z'. SQLite and MySQL accepts this, but PostgreSQL
does not. This bug has been fixed in 1.1.

Testing and review shows no problems with 1.1

docs: smtp_port is now respected by backlash

Support for a custom smtp_port was recently added to backlash, so bump
backlash and update the documentation to reflect that.