Implement 3.x->4.x compatibility service

Write a TK service that handles 3.x URL requests and translates them into the corresponding 4.x requests. For the first pass at this implementation, we should just focus on translating the URL strings appropriately and setting up the service skeleton. URL query parameters and request/response bodies are not expected to require translation, and request headers can be handled in a later ticket.

Tests for this service would mostly happen at the HTTP request/response level, where an 3.x request map is translated into a 4.x request map and validated.

auth.conf will need to be tested in a similar manner by creating a 4.x-style auth.conf and then validating that a 3.x agent is governed appropriately.

Implementation Details (copied from SERVER-526)

UPDATE: We had an engineering meeting on 3/30/15 to discuss this a bit further. Some notes from that meeting:

1) The only Puppet 4 master that will be required to support Puppet 3.x agent request mapping is a Puppet Server 2.x master, not a WEBrick or Rack master. This will allow for us to create a Puppet Server-only solution.

2) The "legacy" and "v2.0" master/CA Compojure routes had been removed for Puppet Server 2.0. These could be basically restored for Puppet Server 2.1, with some middleware function(s) which can transform the URL and request parameters in the Ring request map from the "legacy" / "v2.0" format to corresponding "v3" master / "v1" CA formats, as appropriate. Post-transformation, the request handlers could just call into the same functions that the "v3" master / "v1" CA handlers have been calling into.

Old routes:

https://github.com/puppetlabs/puppet-server/blob/puppet-server-1.0.8/src/clj/puppetlabs/services/ca/certificate_authority_core.clj#L239-L275

https://github.com/puppetlabs/puppet-server/blob/puppet-server-1.0.8/src/clj/puppetlabs/services/master/master_core.clj#L10-L78

3) It would be best for the code involved in performing the "legacy/v2.0" -> "v3" master / "v1" CA transformation to be isolated such that it would would be very straightforward to purge it later on. chris suggested we might be able to do this by consolidating the new code into a service which registers its own independent ring handler with the webserver. That way, removing the remapping logic in a later release would hopefully be as simple as just deleting the service namespaces. We could consolidate the Puppet 3.x compatible CA and master routes into a single service rather than spreading them across 2 services.

4) Remove the "not found" fallback route for the master and CA so that the Puppet 3.x compatible route ring handlers will be evaluated when needed:

https://github.com/puppetlabs/puppet-server/blob/0ca3d679dbdd4749f884729112f2f99aa6d50528/src/clj/puppetlabs/services/master/master_service.clj#L43

Also, take care that no new "not-found" route is added to any of the legacy routes that are being restored so that we don't adversely affect the ability for the new Puppet 4.x routes to be handled properly.

5) Assuming the URL remapping would be occurring at the Compojure route layer, a "legacy" URL would have been transformed into a Puppet 4-compatible URL by the time the incoming request could be evaluated against "auth.conf" rules. There's probably not any unique development work to be done around this aspect, but we should work with the docs team to ensure that this behavior is appropriately documented for users.

QA

Risk assessment: N/A: New Feature: Testing organized in SERVER-595 & SERVER-546