Fully-immutable custom snapshots

[3noch]

Thanks to @snoyberg, we have usable custom snapshots. However, each snapshot must be explicitly and manually named. This has advantages when a user wants fine-grained control of when stack decides to rebuild snapshot components. However, another common use-case would benefit greatly from having stack automatically handle how and when custom snapshots get built.

One example might be when a stack.yaml file is under version control along with a code-base. Alongside the stack.yaml file is a snapshot.yaml file, which, of course, is also under version control. When a user moves HEAD, the snapshot might change. If stack automatically detected this, it could use the new snapshot definition instead of the old one.

A possible implementation might look like making "unnamed" custom snapshots default to an automatically generated name, which is a hash of the snapshot's contents. This would allow stack to build each unique snapshot only once.

So right now stack.yaml might have:

resolver:
  location: snapshot.yaml
  name: custom-snapshot-1.2

[Notice that custom-snapshot must be manually versioned.]

But with this enhancement, stack.yaml could say:

resolver:
  location: snapshot.yaml

And stack would generate the name by hashing the contents. If the location is a remote URL, stack could decide to download it on every build or treat it as an immutable resource and cache its generated name.

[3noch]

@feuerbach Do you have thoughts about this?

[snoyberg]

I think the proposal in #863 will address this fully, closing.

[3noch]

Perfect.