hgweb: send proper HTTP response after uncaught exception

This patch fixes a bug where hgweb would send an incomplete HTTP
response.

If an uncaught exception is raised when hgweb is processing a request,
hgweb attempts to send a generic error response and log that exception.

The server defaults to chunked transfer coding. If an uncaught exception
occurred, it was sending the error response string / chunk properly.
However, RFC 7230 Section 4.1 mandates a 0 size last chunk be sent to
indicate end of the entity body. hgweb was failing to send this last
chunk. As a result, properly written HTTP clients would assume more data
was coming and they would likely time out waiting for another chunk to
arrive.

Mercurial's own test harness was paving over the improper HTTP behavior
by not attempting to read the response body if the status code was 500.
This incorrect workaround was added in ba6577a19656 and has been removed
with this patch.

--HG--
branch : stable
extra : rebase_source : 601db473a64e36171f7f7f21a2e42c0452db64db
mq: fix update of headers that occur in the "wrong" order

Mq tried to insert headers in the right order. Sometimes it would stop
searching before checking all headers and it could thus duplicate a header
instead of replacing it.

--HG--
branch : stable
extra : rebase_source : f11d2f46c07535a926cf09d500532f142574f6fe
i18n-ja: synchronized with edf29f9c15f0

--HG--
branch : stable
revset: fix first and last for generatorset (issue4465)

The code was just plain wrong.

--HG--
branch : stable
help: fix typo in files help

--HG--
branch : stable
hook: raise a more specialized HookAbort exception when a hook fails

We need to gracefully handle some aborts for pushkey, especially
because it leads to a user-facing crash over the wireprotocols. So we
need a more specialized exception to catch.

--HG--
branch : stable
pushkey: gracefully handle prepushkey hook failure (issue4455)

This allow to gracefully report the failure of the bookmark push and carry on.
Before this change set. Local push would plain quit and wireprotocol would
failed in various ungraceful way.

--HG--
branch : stable
tests: clean-up of largefiles tests in test-issue3084.t

Prepare for adding more test cases to the systematic testing, moving the test
from ac3b3a2d976d to another section.

--HG--
branch : stable
tests: add test-issue3084.t cases for 'changed but same' as for 'unchanged'

Use suffix -same for cases where file changed but content is the same - that is
the case where manifestmerge doesn't detect that a file is unchanged.

(The suffix -id is already used for cases where the file didn't change - that
is the trivial case where manifestmerge detects that the file is unchanged.)

These new tests are good but the results are bad. There shouldn't be any merge
conflicts or prompts when one side didn't change.

--HG--
branch : stable
largefiles: don't show largefile/normal prompts if one side is unchanged

--HG--
branch : stable
extra : amend_source : ac631a33e189db4ddf2ddc92be38ed1a73ed4211
merge: before cd/dc prompt, check that changed side really changed

Before, merging would in some cases ask "wrong" questions about
"changed/deleted" conflicts ... and even do it before the resolve phase where
they can be postponed, re"resolved" or answered in bulk operations.

Instead, check that the content of the changed file really did change.

Reading and comparing file content is expensive and should be avoided before
the resolve phase. Prompting the user is however even more expensive. Checking
the content here is thus better.

The 'f in ancestors[0]' should not be necessary but is included to be extra
safe.

--HG--
branch : stable
extra : rebase_source : e4ea7e8e610791609fde60b9c28bdb4015a0e618
i18n-pt_BR: synchronized with 3bd577a3283e

--HG--
branch : stable
extra : rebase_source : 563aaf240449daa047193e25fdbab7ebfba78d0a
Added tag 3.2.2 for changeset 902554884335

--HG--
branch : stable
Added signature for changeset 902554884335

--HG--
branch : stable
merge with i18n

--HG--
branch : stable
merge with stable