Allow remote IPFS node support & IPFS for data retrieval & automatic env wiring

[jsign]

This PR has three changes.

Automatic environment variables wiring for .toml config file
Currently, a user can only change configuration attributes in a .toml file. Now a LOTUS_ prefix is wired to be considered for changing these attributes.
The env variable name respects the logical grouping, some examples of use:

• LOTUS_API_LISTENADDRESS=...
• LOTUS_CLIENT_USEIPFS=...
• LOTUS_METRICS_NICKNAME=...

Environment variables takes precedence over configurations in the .toml file, as usually expected.

Allow using a remote IPFS node as the underlying blockstore
This extends the work done #1641. That meant using a local IPFS node as the underlying block storage for getting data to start deals.
This PRs adds two extra features:

• It allows to use of a remote IPFS node providing its multiaddress API.
• It allows to optionally also use IPFS for storing retrieved data from deals.

This is mapped in the following attributes in the .toml file:

[Client]
# UseIpfs = false
# IpfsMAddr = ""
# IpfsUseForRetrieval = false

(by default setup).

The UseIpfs flag was done in #1641. Now, if UseIpfs=true and want to use a remote IPFS node, its corresponding multiaddr should be set, e.g: IpfsMAddr=/ip4/172.0.9.1/tcp/5001.
This will use the IPFS node only as a source of retrieving data to make new deals.
In case you also want to store data in IPFS when data is retrieved from deals, set IpfsUseForRetrieval=true (saying it differently, IPFS is the Get&Put blockstore for Lotus).

Considering previous point feature, you can also set via envs: LOTUS_CLIENT_USEIPFS=true, LOTUS_CLIENT_IPFSMADDR=..., etc.

Allow "fetching" data instead of necessarily retrieving it to files
Considering the new feature IpfsUseForRetrieval, now allow to "fetch" a Deal data without necessarily dealing with storing the result in files but just feeding IPFS with it.
This basically means that after the call ends, the data will be available in the underlying configured IPFS node for retrieval. This is convenient to avoid dealing with files or duplicating data that we already "fed" into the IPFS node.

To use this feature, call the ClientRetrieve API with a nil *apil.FileRef (now a pointer).

From birds-eye, now Lotus can entirely rely on IPFS for data storage to make deals and retrieve them.

cc @whyrusleeping @magik6k

[magik6k]

Looks good, just 1 comment

[long568]

lotus v1.16.0
Got ERROR
`lo@s003 ~/work $ lotus client retrieve bafkreiffchzrsda6jdjaxavenbjn3e3rq7rosv7tgrmsusdb4ahvvo24am /home/lo/work/123.txt
Failed to find file
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x1a1dba2]

goroutine 1 [running]:
github.com/filecoin-project/lotus/cli.glob..func40(0xc000ec5240)
/home/lo/lotus/cli/client_retr.go:321 +0x502
github.com/urfave/cli/v2.(*Command).Run(0x824e0e0, 0xc000ec4f00)
/home/lo/golang/gopath/pkg/mod/github.com/urfave/cli/v2@v2.3.0/command.go:163 +0x5bb
github.com/urfave/cli/v2.(*App).RunAsSubcommand(0xc000183a00, 0xc000ec4c00)
/home/lo/golang/gopath/pkg/mod/github.com/urfave/cli/v2@v2.3.0/app.go:434 +0xc8a
github.com/urfave/cli/v2.(*Command).startApp(0x824e440, 0xc000ec4c00)
/home/lo/golang/gopath/pkg/mod/github.com/urfave/cli/v2@v2.3.0/command.go:278 +0x713
github.com/urfave/cli/v2.(*Command).Run(0xc00068de00?, 0x7?)
/home/lo/golang/gopath/pkg/mod/github.com/urfave/cli/v2@v2.3.0/command.go:94 +0xba
github.com/urfave/cli/v2.(*App).RunContext(0xc000183520, {0x4a61cc0?, 0xc0000520d0}, {0xc00004e0a0, 0x5, 0x5})
/home/lo/golang/gopath/pkg/mod/github.com/urfave/cli/v2@v2.3.0/app.go:313 +0xb48
github.com/urfave/cli/v2.(*App).Run(...)
/home/lo/golang/gopath/pkg/mod/github.com/urfave/cli/v2@v2.3.0/app.go:224
github.com/filecoin-project/lotus/cli.RunApp(0x38f7fc0?)
/home/lo/lotus/cli/helper.go:35 +0x4e
main.main()
/home/lo/lotus/cmd/lotus/main.go:111 +0x8ec`