tests: set app_globals and translater in conftest.py for py.test

Copy over code from the pylons nose plugin for setting app_globals and for
setting a translator object.

This allows more of the functional tests to pass; particularly the ones related
to i18n.

tests: Destroy user_user_group 'perms_group_1'

This doesn't seem to be a problem when running `nosetests`, but with `py.test` for some reason it becomes a problem:

$ py.test kallithea/tests/models/test_user_permissions_on_repo_groups.py kallithea/tests/models/test_user_group_permissions_on_repo_groups.py --maxfail=1 --tb=short
...
build/bdist.macosx-10.6-intel/egg/sqlalchemy/engine/default.py:331: in do_execute
cursor.execute(statement, parameters)
E IntegrityError: (IntegrityError) UNIQUE constraint failed: users_groups.users_group_name
u'INSERT INTO users_groups (users_group_name, user_group_description, users_group_active, users_group_inherit_default_permissions, user_id, created_on, group_data) VALUES (?, ?, ?, ?, ?, ?, ?)' ('perms_group_1', 'DESC', 1, 1, 2, '2015-04-08 17:38:03.457963', None)
...

tests: Eliminate use of nose.tools.with_setup - it is nose-specific

Instead, simply make `permissions_setup_func` set the baseline permissions.

tests: Make `parameterized` stuff work with both pytest and nose

- Use `nose.tools.nottest` if `nose` is available
- Use `pytest.mark.skipIf` if `pytest` is available
- Rename from `nose_parametrized` to `parameterized` since it's no longer
nose-specific

tox.ini: Set PYTHONHASHSEED = 0

because there is some non-deterministic stuff that can fail without this

setup: bump mercurial requirement to 2.9

Commit 1cd9bdf1362d started using iterbranches() method of branchmap

security: Fix HTML and JavaScript injection.

This fixes CVE-2015-1864

i18n: updated translation for Hungarian

Currently translated at 1.0% (12 of 1116 strings)

setup: bump mercurial requirement to 2.9

Commit 1cd9bdf1362d started using iterbranches() method of branchmap

tests: Add conftest.py for pytest

This adds a conftest.py for pytest that initializes the Pylons app so that the
SQLAlchemy session is bound and such.

This is sort of the Python analogue for the nosetest plugin that Pylons
includes: https://github.com/Pylons/pylons/blob/master/pylons/test.py

tests: PEP8ify test_user_groups.py

This eliminates flake8 warnings:

kallithea/tests/models/test_user_groups.py:3:1: F403 'from kallithea.tests import *' used; unable to detect undefined names
kallithea/tests/models/test_user_groups.py:22:5: E303 too many blank lines (2)

tests: Remove imported_from_test function

AFAICT, this function is not used:

$ ag imported_from_test
kallithea/tests/nose_parametrized.py
144:def imported_from_test():

.hgignore: Add .eggs/ and tarballcache/

Setuptools >= 7.0 and .eggs is created and populated with eggs if setup.py has
setup_requires of packages that are not installed and setuptools has to
download them to satisfy the requirements. See
https://bitbucket.org/pypa/setuptools/pull-request/97/cache-eggs-required-for-building-in-eggs/diff#

tarballcache comes from test.ini : archive_cache_dir = %(here)s/tarballcache

auth: check CSRF protection token when authenticating

Use pylons secure_form to get CSRF protection on all authenticated POSTs. This
fixes CVE-2015-0276.

GETs should not have any side effects and do thus not need CSRF protection.

Reported by Paul van Empelen.

tests: provide _authentication_token when POSTing

So far not used, just preparing for the the time when the actual checking is
introduced ...

This change is very verbose. self.app.post should perhaps just at this value
automagically ...

javascript: provide secure_form compatible_authentication_token in all AJAX POSTs

_authentication_token is introduced as a global javascript variable. That seems
less ugly than passing it through as parameter everywhere ... and the token
really _is_ a global thing.

forms: use secure_form to add authentication token to all html forms

Towards CSRF protection ... but not yet checked

manifest: include (almost) all repo files in the release tar

Before running sdist, make sure it contains exactly the right files by running:
hg purge --all
python setup.py compile_catalog

i18n: don't include .mo files in the repo - build them on demand

(We do however keep the english .mo for now to preserve backwards
compatibility.)

i18n: drop redundant english translation

lang should thus be set empty instead of 'en', but we keep the en .mo around
to avoid upgrade issues.

i18n: remove translations that 5e7bdfbef29b made both fuzzy and invalid

Get rid of compile_catalog errors.

i18n: updated translation for Polish

Currently translated at 65.4% (730 of 1116 strings)

i18n: updated translation for Slovak

Currently translated at 4.5% (51 of 1116 strings)

i18n: updated translation for German

Currently translated at 42.7% (477 of 1116 strings)

i18n: updated translation for Russian

Currently translated at 77.5% (866 of 1116 strings)

summary: repeat repo type in front of clone URL

Repeatedly, users report cloning problems of the Kallithea sources on IRC,
caused by them assuming that it is a Git repository.

Try to solve this problem by repeating the repository tag, indicating 'hg'
or 'git' in front of the clone URL.

Additionally, decrease the font size of the URL a notch, and improve
alignment with the repotag by removing top/bottom padding.

To avoid duplication of the repotag logic, introduce a mako def for it.

docs: create separate 'Administrator guide'

The current 'Usage' section combines real usage information (intended for
repository owners) with information for administrators.
Instead, create a distinct 'administrator guide'.

docs/usage: move Mercurial subrepository info to VCS support page

This commit moves the information verbatim, text changes will be done in a
subsequent commit.

docs/usage: generalize 'git support' into 'version control systems support'

Rename and rework the 'git support' page such that it can hold information
about Mercurial as well.

docs/usage: fix section 'trending source files'

The source code reference for the 'trending source files' dictionary was no
longer correct, so update it.
Additionally, some small rewording.

docs/usage: rework and rename section 'Visual settings in admin pannel'

- remove trivial items that are already explained on the settings page
itself
- rename section to reflect this new scope
- general rewording

docs: update the translation howto

* Reformat to RST
* Add sections about using Weblate

i18n: updated translation for Dutch (Belgium)

Currently translated at 0.8% (9 of 1077 strings)

i18n: updated translation for German

Currently translated at 47.5% (512 of 1077 strings)

i18n: updated translation for Slovak

Currently translated at 3.8% (41 of 1077 strings)

javascript: use jQuery $.post instead of YAHOO.util.Connect.asyncRequest

ajaxPOST will add the extra custom X-PARTIAL-XHR header ... but it does no harm
in these cases.

setup: constrain dulwich to version 0.9.9

65c5e70a1d0c bumped the version to 0.10 but there seems to be some unicode
compatibility issues there. So for now, just stay on 0.9.9 which both works and
has the fix for CVE-2015-0838.

repo: remove old ez_setup.py

The purpose of this script was to download and install easy_install... which is
years past its expiration date. Instead, let's revamp and recommend newer tools
in the docs and start by removing this file.

style: remove css star hack for internet explorer 7

This is invalid css and only works on decrepit browsers. Remove it.

style: stop supporting internet explorer 6-8 gradients

This 'progid:' line was non-standard and is no longer needed for modern
browsers, including Internet Explorer > 9. Besides, all it did was add a
gradient, so not really that much of a loss for someone using an decrepit
browser.

controllers: consistently use formfill.render with force_defaults=False

The inconsistency could cause confusion for developers. It seems to me like
force_defaults=False should be the default ... and apparently it was that in
older versions of formfill.

It could perhaps make sense for us to have a wrapper that added the defualt
values once, instead of repeating it all over ;-)

pullrequests: saving raw_id instead of branch in org_ref

This fixes an issue when the pull request is created while the top commit
included is not the tip. In that case, the faulty code would but
branch:default:default as org_ref, that causes the pull request view to show
all commits on that branch instead of the wanted commit(s) only. The fix will
result in a branch:default:1234567890abcdef1234567890abcdef (e.g)