Enable fetching of cf app binary bits by other TF providers

[gberche-orange]

This is a split of #38

It seems like the repo package is pulling a release locally, modifying it, and then it will be pushed up to Cloud Foundry as part of the resource_cf_app, is that understanding correct?
[...]
FWIW you may want to try to integrate this using an addition to the GitHub provider, HTTP, or Archive providers so you aren't left having to implement things like this for every possible storage location.

In order to maintain good balance between:

• need to release 1.0 quickly
• need to preserve backward compatibility in the future
• reduce duplication between terraform-provider-cf and other providers: So that other providers can be improved to support CF use cases and relief the terraform-provider-cf from handling these cases.

We plan to mark the current git and github_release attributes as deprecated, so that users can choose not to rely on them to avoid future backward incompatibility. In addition, illustrate how other focused providers can be used to fetch the app binaries. See https://github.com/ArthurHlt/terraform-provider-zipper for a suggestion by @ArthurHlt

• Check support for local CF_app archive using the cf_app.url attribute as the documentation suggests below. Document the archive format (zip, gnu tar.gz). If possible, add test coverage into resource_cf_app_test.go

One of the following arguments must be declared to locate application source or archive to be pushed

• Check cf_app.url attribute specifying a local archive can be indeed combined with the cf_app.add_content attribute. If possible, add test coverage into resource_cf_app_test.go
• Submit issues to HTTP, Archive, github providers to add support needed by terraform-provider-cf
  • https://github.com/terraform-providers/terraform-provider-http : HTTP datasource only supports text/* or application/json content types.
    • It should be able to download any public archive,
    • expose an output attribute providing access to a local path on the file system, and possibly have it ephemeral (i.e. cleaned up upon TF process exit)
    • expose additional attributes to optimize case when attribute is not modified, eg.
      • ETag/Last modified date from HTTP headers
      • Hash of the content (e.g. MD5)
  • GitHub provider does not offer a repository or release datasource that can fetch either a git repo or a github release, be it public or private
• Deprecate git and github_release release attributes, explaining future support for other providers (Git, Github, HTTP)
  • Provide an example in documentation of leveraging an external provider to fetch cf app bits binary.

[ArthurHlt]

My first concern is that there is no provider for git and in fact release from github or gitlab or whatever version control SaaS can be downloaded directly in http. Clone and create archive from git is a nice feature but can't be added to an existing provider (as git is agnostic to github or gitlab)

zipper, lib which used by terraform-provider-zipper, has been made to avoid download everything if a signature doesn't change (it tries to create the signature from a small chunk of data).

This signature can be used like i was doing on the old cloud foundry provider (see: https://github.com/orange-cloudfoundry/terraform-provider-cloudfoundry/blob/master/resources/apps.go#L766-L773 ), Hashicorp are actually doing the same thing on AWS Lambda function as we can see here: https://www.terraform.io/docs/providers/aws/r/lambda_function.html (see paramaters filename and source_code_hash).

Zipper might be the solution for both provider but there is another things which actually being used by hashicorp called go-getter. This is used to download modules for terraform but it could be used as a provider to download bits from different locations (we can see documentation about how to retrieve git archive in module documentation: https://www.terraform.io/docs/modules/sources.html#generic-git-repository ).

I see 2 missing features on go-getter:

1. Doesn't create signature (create signature as I do on zipper will be great)
2. This unarchive archive but we, obviously, need to create one on AWS Lambda function and our provider (but workaround can be found in those providers)

I would be greatly interested by your inputs @paultyng (specifically the last part about go-getter).

@mevansam and @psycofdj your thoughts/ideas are welcome too

[mevansam]

@ArthurHlt I like the idea of having a separate provider like terraform-provider-zipper to do this rather than reusing go-getter, as I see that this capability may be useful for other providers that may require access to downloadable resources.

[gberche-orange]

Moving to 1.0 milestone as spawning the app artefact output out of cloudfoundry_application will be a breaking change.

This should also help shrink the provider code base and avoid having to deal with logic such as #198

[ArthurHlt]

implemented on #203