(PUP-2659) Synchronize all webrick requests.

Puppet had some scattered thread safety code, which was removed in
4da350b, because Puppet itself is not using threads.  However, Webrick
starts a new thread to handle each incoming request.  This was probably
causing subtle problems during simultaneous requests to a webrick
master, but since 3.6.1 the issue became much more noticeable due to the
fix for PUP-2610 merged in 0dc5ad3 which was fixing a case where rack
masters would lose track of newly established environment loaders using
the master settings.  The change to Puppet::Context used a new
mark/rollback method for overriding context making it very obvious when
concurrent threads would collide attempting to rollback the same marker
and exhaust the context stack.

We are fixing this by synchronizing around incoming webrick requests,
effectively serializing their access to Puppet's innards.  Initial
manual benchmarking did not show a significant decrease in performance,
probably because Ruby uses green threads handled by the vm which cannot
take advantage of multiple processors.
(PUP-2659) Add a concurrency acceptance test

It is difficult to test concurrent requests with Beaker as it does not
allow parrallel requests to be made.  I'm using backgrounded subprocess
in a shell script to get around this, and I'm only making direct catalog
requests via curl, since an agent will halt if it spots another's pidfile in
existence on the same node.  Still, this is one of the major calls that
the agent makes, and it does effectively expose PUP-2659 on a
non-synchronized webrick master.
Merge pull request #2708 from jpartlow/issue/stable/pup-2659-synchronize-webrick-rest

Issue/stable/pup 2659 synchronize webrick rest