sslutil: prevent CRIME ssl.create_default_context() disables compression on the TLS channel in order to prevent CRIME. I think we should follow CPython's lead and attempt to disable channel compression in order to help prevent information leakage. Sadly, I don't think there is anything we can do on Python versions that don't have an SSLContext, as there is no way to set channel options with the limited ssl API.

sslutil: update comment about create_default_context() While ssl.create_default_context() creates a SSLContext with reasonable default options, we can't use it because it conflicts with our CA loading controls. So replace the comment with reality. (FWIW the comment was written before the existing CA loading code was in place.)

tests: use sslutil.wrapserversocket() Like the built-in HTTPS server, this code was using the ssl module directly and only using TLS 1.0. Like the built-in HTTPS server, we switch it to use sslutil.wrapserversocket() so it can follow better practices.

hgweb: use sslutil.wrapserversocket() This patch transitions the built-in HTTPS server to use sslutil for creating the server socket. As part of this transition, we implement developer-only config options to control CA loading and whether to require client certificates. This eliminates the need for the custom extension in test-https.t to define these. There is a slight change in behavior with regards to protocol selection. Before, we would always use the TLS 1.0 constant to define the protocol version. This would *only* use TLS 1.0. sslutil defaults to TLS 1.0+. So this patch improves the security of `hg serve` out of the box by allowing it to use TLS 1.1 and 1.2 (if available).

sslutil: implement wrapserversocket() wrapsocket() is heavily tailored towards client use. In preparation for converting the built-in server to use sslutil (as opposed to the ssl module directly), we add wrapserversocket() for wrapping a socket to be used on servers.

hgweb: pass ui into preparehttpserver Upcoming patches will need the built-in HTTPS server to be more configurable.

rebase: remove sortedstate-related confusion The following rebase implementation details are frustrating: - storing a list of sorted revision numbers in a field named sortedstate - having sortedstate be a field of the rebaseruntime class - using sortedstate[-1] as opposed to a more intuitive max(self.state) to compute the latest revision in the state This commit fixes those imperfections.