Hardening Updates with Content-Addressing and IPNS

> Use of Electron Builder's Auto Update is tracked in https://github.com/ipfs-shipyard/ipfs-desktop/issues/668.

> **This is a placeholder issue** about hardening the Auto Update process by introducing an additional IPFS-based integrity check that does not depend on Electron Builder service based on GitHub Releases.

We will create a proper threat model when Security WG is formed later in 2019, for now let's assume scenario where malicious update gets published via GitHub Releases.

Potential mitigation:
1. Detect update happened
2. Validate binary before first run:
1. Get the CID of the local file via `ipfs add --only-hash `
2. Compare against ``
(value should be independent of GitHub Releases)

Impacted users:
- Mac and Windows users (Electron Builder's Auto Update)
- Linux/*BSD users that do not use Snap package, but installed update from distribution-specific package created by third party developers.
- Users that choose to manually update the go-ipfs binary or using the `ipfs-update` tool

Open questions:
- [ ] How to detect auto update happened?
- [ ] Should we also detect go-ipfs binary changed? (check before every run)
- [ ] How to handle js-ipfs? (no fat binary)
- [ ] What will be the source of "valid" CIDs of go-ipfs binaries? IPNS?
- Right now http://dist.ipfs.io provides CID of `.zip`/`.gz` archive ([example](http://127.0.0.1:8080/ipns/dist.ipfs.io/go-ipfs/v0.4.18/go-ipfs_v0.4.18_windows-386.zip.cid)), which is not useful for this exact case, but we could create something similar for unpacked binaries and publish it on IPNS under known key (lack of DNSLink removes the risk of DNS MITM and replaces it with pure IPNS+IPFS integrity guarantees)