Output variable values used and obfuscate sensitive values

[krantzinator]

This PR adds support for obfuscating variables set to sensitive in the waypoint.hcl, and also supports displaying the final variable values in CLI output and logs, as well as the UI (though this part is only supported and not yet implemented).

This will allow users to see the used variable values upon the completion of a job, as well as enable us to add support for actually looking up which values were used on a given build/deploy/release.
This also enables future improvements such as a "noop" dry-run that returns the values that would be used if an operation was completed.

sensitive values are called sensitive to match what Terraform and Packer call them, to give consistency among our HashiCorp products. Unique to Waypoint though is the obfuscation of the values by using SHA256 encoding. This is not meant to be a security mechanism -- the values are stored on the server, which must be secured by the user -- but it does serve as a way to both obfuscate the values in logging and other outputs, while still enabling a user to verify that the value they expected the job to run with was the final value used.

The final values are stored as Variable_Refs so as to separate the values set on the server (when a user saves a value in the UI) and the final set of values used. This also enables an easier format for easily translating to logs and outputs.

The Sensitive item is added to the Variable message to support further communication between the UI and the variables set in the waypoint.hcl as part of future improvements.

To see it in action, you can use the below waypoint.hcl on our waypoint-examples/docker/go project:

project = "example-go"

app "example-go" {
  labels = {
    "service" = "example-go",
    "env"     = "dev"
  }

  build {
    use "pack" {}

    registry {
      use "docker" {
        image = "rae/go"
        tag   = var.tag
        local = var.local
      }
    }
  }

  deploy {
    use "docker" {}
  }
}

variable "tag" {
  type = string
  sensitive = true
  default = "hello"
}

variable "local" {
  default = true
}

To see how complex HCL types come through, replace the variable definition and usage of tag with:

...
        tag   = var.tag[0]
...
variable "tag" {
        type       = list(string)
        default   = ["hello", "othertag", "moretag", "whatifi", "havelotsof", "tagsand things"]
}

A couple of screenshots showing some example outputs:

An example of the line breaks I was going for; without the manual line break intervention, the use of variable values longer than the terminal width severely messed up the column title widths:

[briancain]

Oops, I hit submit too fast! I also ran into a weird thing where this string input var was right aligned? Very strange, not sure what's going on there 🤔

» Variables used:
     VARIABLE    |         VALUE         |  TYPE  | SOURCE
-----------------+-----------------------+--------+----------
  image          | localhost:5000/tetris | string | cli
  namespace      |                       | string | default
  registry_local | false                 | bool   | cli
  release_port   |                  3000 | string | default
  tag            | latest                | string | default

The input var is defined as:

variable "release_port" {
  default     = "3000"
  type        = string
  description = "Port to open for the releaser."
}

[briancain]

This looks awesome @krantzinator !! Excited for this feature to land. I haven't had a chance to review the rest, mostly coming at it from the UX side. But looking pretty good from that direction 👍🏻

[xiaolin-ninja]

As is, the first chunk would be 46 chars because of indexing.

Suggested change

	val = val[:i] + "\n" + val[i:]
	val = val[:i-1] + "\n" + val[i:]

[krantzinator]

I'm just going to make this i%45; the indexing 😵 got me but that's what I want -- up to the first 45 chars inclusive (index 0-44), and then the next set exclusive ([45:].

[xiaolin-ninja]

Ah, I tested this and if you do i%45 it doesn't crop right! The first chunk ends up as 45 chars but every subsequent chunk is only 44. @krantzinator

[mitchellh]

I didn't do a full line by line review because I think there is enough in my feedback.

The core logic here feels really solid. I have some important feedback on the structure of the data and where it lives. But the actual core encoding of the values and storage generally is great.

[xiaolin-ninja]

Just in case this comment got lost in the rebasing, for the manual line break logic, just changing it to i%45 like:

if i%45 == 0 && i != 0 {
  val = val[:i] + "\n" + val[i:]
  ...
}

won't fix it, because the first chunk will be alright at 45 chars, but subsequent chunks will be 44 chars.

But my original proposed solution also isn't right either, because it'll drop a char in between each chunk. This should work:

	if len(val) > 45 {
		for i := 45; i < len(val); i += 46 {
			val = val[:i] + "\n" + val[i:]
		}
	}