exchange: support preserving external names when parsing bundle specs This will be needed to make client-side preferences work easier.

clonebundles: filter on SNI requirement Server Name Indication (SNI) is commonly used in CDNs and other hosted environments. Unfortunately, Python <2.7.9 does not support SNI and when these older Python versions attempt to negotiate TLS to an SNI server, they raise an opaque error like "_ssl.c:507: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure." We introduce a manifest attribute to denote the URL requires SNI and have clients without SNI support filter these entries.

clonebundles: filter on bundle specification Not all clients are capable of reading every bundle. Currently, content negotiation to ensure a server sends a client a compatible bundle format is performed at request time. The response bundle is dynamically generated at request time, so this works fine. Clone bundles are statically generated *before* the request. This means that a modern server could produce bundles that a legacy client isn't capable of reading. Without some kind of "type hint" in the clone bundles manifest, a client may attempt to download an incompatible bundle. Furthermore, a client may not realize a bundle is incompatible until it has processed part of the bundle (imagine consuming a 1 GB changegroup bundle2 part only to discover the bundle2 part afterwards is incompatibl). This would waste time and resources. And it isn't very user friendly. Clone bundle manifests thus need to advertise the *exact* format of the hosted bundles so clients may filter out entries that they don't know how to read. This patch introduces that mechanism. We introduce the BUNDLESPEC attribute to declare the "bundle specification" of the entry. Bundle specifications are parsed using exchange.parsebundlespecification, which uses the same strings as the "--type" argument to `hg bundle`. The supported bundle specifications are well defined and backwards compatible. When a client encounters a BUNDLESPEC that is invalid or unsupported, it silently ignores the entry.

clonebundle: support bundle2 exchange.readbundle() can return 2 different types. We weren't handling the bundle2 case. Handle it. At some point we'll likely want a generic API for applying a bundle from a file handle. For now, create another one-off until we figure out what the unified bundle API should look like (addressing this is a can of worms I don't want to open right now).

update: also use 'destupdate' for pull and unbundle Update can also be performed by 'hg pull --update' and 'hg unbundle'. We use the destupdate function in these case too.

destupdate: also include bookmark related logic For the same reason, we move the bookmark related update logic into the 'destupdate' function. This requires to extend the returns of the function to include the bookmark that needs to move (more or less) and the bookmark to activate at the end of the function. See function documentation for details on this returns.