Simplify Dependencies

[coreyti]

PR Overview (three changes):

1. Packaging and installation of gem dependencies now use a custom vendor/package path. The vendor/cache path is not used, as that is a special path managed by Bundler and, when present, will include all of the gems referenced by the project, including the development gems that we want to exclude in the built release.
2. Switches to using Bosh::Cpi::RegistryClient, so we can remove the dependency on bosh-registry, thereby also removing many transitive dependencies that are not actually need for the CPI.
3. Removes the publication the CPI as a gem, as that is unnecessary for this library.

Notes of Interest:

• For the time being, we need to lock the bosh_cpi dependency to a slightly older version. This is because the newest versions at this point in time were build from "hotfixes" and do not include the Bosh::Cpi::RegistryClient change. Once that change makes it to "master", and subsequent gems are published, this version lock should be removed (along with the bosh-common lock).
• It is possible (likely?) that the version of Bundler included in the CPI release needs to be updated for these changes to work when deployed. I could not make that change as part of this PR, as I wouldn't have been able to sync the blobs without blobstore access. While this might not actually be required (all of the relevant Bundler ENV config options are found in version 1.8.2), I recommend that the version be bumped to latest: 1.11.2

Context/Details from an Earlier Conversation with Abel:

"vendor/cache" is a special/magical path that bundler (and/or rubygems) recognizes as a place to install (cache) gems. The simple presence of that directory path will make bundle install update the gems therein.

<current directory>/.bundle/config is also a special path/file where bundler will store configuration of custom options you provide for bundler commands executed.

Given the typical workflow of a developer, bundler will respect and update any provided options from/to .bundle/config, and it will add/remove gems at the vendor/cache path, simply because that path exists.

So, in order to allow the typical developer workflow to remain, we need to continue to allow all gems to be updated in that special path, and all options to be respected/updated in the configuration file.

However, because we want to have a "production" subset of gems included in the published release, we want to ignore those developer gems and developer settings.

So we:

• A) set a custom BUNDLE_CACHE_PATH to install non-dev/-test gems to some other path
• B) execute bundle package with BUNDLE_WITHOUT set, so we exclude dev and test gems when "packaged" to that path,
• C) set BUNDLE_APP_CONFIG to a temporary path so we don't update the local .bundle/config settings for the developer, but rather write to a configuration file that we can subsequently throw away.

The result of all of that is that we have two caches:

• A) vendor/cache with all of the gems needed for working on the project
• B) vendor/package with only those gems needed for production

(the specific gem versions for the two caches are kept in sync by way of the Gemfile.lock)

So, our developers can have whatever special configuration they want or need (in .bundle/config) without affecting or being affected by the vendor_gems script. And that script packages only the gems we need for production into (the git-committed vendor/package path)

Then of course, on the BOSH release packaging side, we want to be sure we are:

• A) in fact only including the production gems (those in vendor/package) in the built release... hence the customization of paths in the spec file
• B) able to install the gems from our custom package/cache path... hence the matching bundler configuration in the packaging script.