hgwebdir: use web.prefix when creating url breadcrumbs (issue3790)

The web.prefix setting was being ignored when creating the index URL
breadcrumbs.

We only need to fix hgwebdir and not hgweb because hgweb gets the complete URL
request, including the prefix, while hgwebdir gets a "subdir" which does not
include the prefix.

This fix is slightly different of what was suggested on the bug tracker. In
there it was suggested to hide the prefix itself from the breadcrumb. I think
that would be a better solution, but it would require changing all the index
templates and passing the prefix to the template engine, which may be too big
a change for stable during the freeze. For now this fixes the problem, and the
fix could be improved during the next cycle.

--HG--
branch : stable
extra : histedit_source : 71eef0e89c1b6507a45eda6661aca59cc51d52a1
rebase: mention phases in the help

Mention that Mercurial helps you not do what you've just been warned not
to do, with a reference to the 'phases' help topic (not the 'phase'
command help).

Thanks to Pierre-Yves David <pierre-yves.david@ens-lyon.org> for
motivating this change and Wagner Bruna
<wagner.bruna+mercurial@gmail.com> for advising on how to do it in an
i18n-friendly way.

--HG--
branch : stable
extra : histedit_source : 1e9739d979d56fa702a584eb91f3fffccd1ac5db
hgweb: remove baseline info from paper template

The user interface introduced in d605a82cf189 is not considered ready
for prime time yet. The internal code stays in place for custom template
usage. The feature is ultimately wanted and will be re-enabled soon. The
current issue is only related to the visual of the current interface.

--HG--
branch : stable
extra : histedit_source : 72872ff4f563424c9c730249e7bcf821de89ff13
rebase: mention --rev in the help

This changeset adds a small mention of it in the help to prevent
confusion. This small addition references online help that is easier to
update and improve at release time.

Following Wagner Bruna's advice, this is added in a plain new paragraph
to not invalidate current translation this close to the release.

--HG--
branch : stable
tests: fix toctou race in tinyproxy.py (issue3795)

test-http-proxy.t sometimes failed with:
    File ".../tests/tinyproxy.py", line 110, in _read_write
      data = i.recv(8192)
  error: (104, 'Connection reset by peer')

This might have started showing up with a9fd11ffa13f ... but it has apparently
also been seen before. I don't see anything in a9fd11ffa13f that can explain
it. It seems to be a race in test, in the tinyproxy helper:

Tinyproxy found an incoming socket using select(). It would break the loop if
an error had been detected on the socket, but there was no error and it tried
to recv() from the socket. That failed - apparently because it had been reset
after select().

Errors in the recv() will now be caught and will break the loop like errors
detected by select() would.

(send() could also fail in a similar way ... but using the same solution there
and losing data we have read doesn't feel right.)

--HG--
branch : stable
subrepo: allows to drop courtesy phase sync (issue3781)

Publishing server may contains draft changeset when they are created locally. As
publishing is the default, it is actually fairly common. Because of this
"inconsistency" phases synchronization may be done even to publishing server.

This may cause severe issues for subrepo. It is possible to reference read-only
repository as subrepo. Push in a super repo recursively push subrepo. Those
pushes to potential read only repo are not optional, they are "suffered" not
"choosed". This does not break because as the repo is untouched the push is
supposed to be empty. If the reference repo locally contains draft changesets, a
courtesy push is triggered to turn them public. As the repo is read only, the
push fails (after possible prompt asking for credential). Failure of the
sub-push aborts the whole subrepo push. This force the user to define a custom
default-push for such subrepo.

This changeset introduce a prevention of this error client side by skipping the
courtesy phase synchronisation in problematic situation. The phases
synchronisation is skipped when four conditions are gathered:
- this is a subrepo push, (normal push to read-only repo)
- and remote support phase
- and remote is publishing
- and no changesets was pushed (if we pushed changesets, repo is not read only)

The internal config option used in this version is not definitive. It is here to
demonstrate a working fix to the issue.

In the future we probably wants to track subrepo changes and avoid pushing to
untouched one. That will prevent any attempt to push to read-only or unreachable
subrepo.

Another fix to prevent courtesy push from older clients to push to newer server
is also still needed.

--HG--
branch : stable
hgweb: returns 404 for unknow revision instead of 500

I noticed that access to filtered revision returned HTTP 500 code (internal
server error). Investigation shown that it was the case for unknown revision
too. That wrong and we now properly return a 404 for revision not found.

--HG--
branch : stable