Add ENV overrides for @build.managed and @build.management_server

These will be useful as command line flags to a package build,
so we enable setting them via ENV['MANAGED'] and ENV['MANAGEMENT_SERVER'].

This way we can test the management via command line without modifying build
parameters.

Signed-off-by: Moses Mendoza <moses@puppetlabs.com>
Update check_var to return the variable being checked

This makes check_var slightly more useful for inline assignments. This is fully
backwards compatible.

Signed-off-by: Moses Mendoza <moses@puppetlabs.com>
temporarily disable curl
Temporarily comment inaccessible methods
Add support for modifying tasks on the fly for build manager

Modify existing Rake tasks with behavior to support managed builds Use
monkey-patched #unshift method and existing #enhance method to enable
inserting actions into already defined rake tasks on the fly.

For core tasks (e.g. pl:deb, package:tar, etc) we use #enhance to add an
additional execution block after the existing tasks, containing a status post
to the build server. Each individual task (e.g. deb cow build) has to post a
status, which is why we're adding at this level. Once the task finishes it posts to the build manager that it has completed.

For aggregate-style task, e.g. "pl:jenkins:uber_build" we prepend to the
existing execution blocks with one which notifies the build manager that a
build has started. Prepending to existing execution blocks offers the ability
to retain all existing task behavior including order in dependencies.

The downside of this approach over @branan's approach is that there is no
explicit failure state from a failed package task, because if a task throws an
exception in one block, Rake will not continue with the remaining blocks. This
means a failure will always mean a timeout, because the core task will never post a status if it fails.

The upside of this approach is that it is much cleaner (for varying definitions
of clean) in that does not add more tasks or clutter to the packaging repo, and
is largely transparent to all existing users. Just add MANAGED=true and the
rest is taken care of for you.
Add task.count to params to post_managed_build_start

This commit removes @count as an instance variable of the BuildManager class,
since its only ever used as a parameter to the managed build start method.
Instead we just pass it in as part of the call to the method. This will rely on
"count" living somewhere else - we're going to add it to the task itself, by
monkey-patching @task_count as a Rake::Task instance variable.

Signed-off-by: Moses Mendoza <moses@puppetlabs.com>
Monkey patch in @count into Rake::Task

This allows us to keep track of how many different tasks we anticipate a task
will kick off. This will allow us to know, for example, how many internal
"pl:deb" calls a pl:jenkins:deb_all call will make, which will then allow us to
track progress of the individual tasks from the build manager. This commit
includes a basic test to ensure instances of Rake::Task have accessors for
@count.

Signed-off-by: Moses Mendoza <moses@puppetlabs.com>
Set counts on the task objects, remove old make_managed_task methods

Signed-off-by: Moses Mendoza <moses@puppetlabs.com>
Add a target_count utility

Just returns the number of targets we can expect given an aggregate build task.

Signed-off-by: Moses Mendoza <moses@puppetlabs.com>
Set counts on the task objects, remove old make_managed_task methods

We're only going to support build coordination for uber_build tasks, for pe and
foss. This dramatically simplifies the logic needed to dynamically prepend
aggegrate task execution with a call to start a build manager watcher, because
the uber_build tasks are aggregates of aggregates. If we supported deb_all and
mock_all, we'd have to figure out some way to selectively prepend based on
which task we're going to eventually use, which is unreliable.

Signed-off-by: Moses Mendoza <moses@puppetlabs.com>
Remove remaining tasks from original implementation of build manager
Update README.md