hgweb: don't redundantly pass templater with requestcontext (API) The requestcontenxt has a ``tmpl`` attribute to access the templater. We don't need to pass the templater explicitly when passing a requestcontext instance. .. api:: Various helper functions in hgweb.webutil no longer accept a templater instance. Access the templater through the ``web`` argument instead. Differential Revision: https://phab.mercurial-scm.org/D2801

hgweb: use templater on requestcontext instance After this commit, all @webcommand function no longer use their "tmpl" argument. Instead, they use the templater attached to the requestcontext. This is the same exact object. So there should be no difference in behavior. Differential Revision: https://phab.mercurial-scm.org/D2800

hgweb: add a sendtemplate() helper function This pattern is common. Let's make a helper function to reduce boilerplate. We store the "global" template on the requestcontext instance and use it. The templater used by the helper function is the same templater that's passed in as an argument to the @webcommand functions. It needs to be this way because various commands are accessing and mutating the defaults on the templater instance. Differential Revision: https://phab.mercurial-scm.org/D2799

hgweb: use web.req instead of req.req We now have access to the modern request type on the requestcontext instance. Let's access it from there. While we're here, remove an unused argument from _search(). Differential Revision: https://phab.mercurial-scm.org/D2798

hgweb: stop setting headers on wsgirequest All commands now go through the new response API. This is dead code. Differential Revision: https://phab.mercurial-scm.org/D2797

hgweb: always return iterable from @webcommand functions (API) We had to hack up this function to support our transition to the new response API. Now that we're done with the transition (!!), we can return to returning an iterator of content chunks from these functions. It is tempting to return a normal object and not a generator. However, as the keyword extension demonstrates, extensions may wish to wrap commands and have a try..finally block around execution. Since there is a generator producing content and that generator could be executing code, the try..finally needs to live for as long as the generator is running. That means we have to return a generator so wrappers can consume the generator inside a try..finally. .. api:: hgweb @webcommand functions must use the new response object passed in via ``web.res`` to initiate sending of a response. The hgweb WSGI application will no longer start sending the response automatically. Differential Revision: https://phab.mercurial-scm.org/D2796

hgweb: send errors using new response API Our slow march off of wsgirequest continues. Differential Revision: https://phab.mercurial-scm.org/D2795

hgweb: refactor 304 handling code We had generic code in wsgirequest for handling HTTP 304 responses. We also had a special case for it in the catch all exception handler in the WSGI application. We only ever raise 304 in one place. So, we don't need to treat it specially in the catch all exception handler. But it is useful to validate behavior of 304 responses. We port the code that sends a 304 to use the new response API. We then move the code for screening 304 sanity into the new response API. As part of doing so, we discovered that we would send Content-Length: 0. This is not allowed. So, we fix our response code to not emit that header for empty response bodies. Differential Revision: https://phab.mercurial-scm.org/D2794