feat: start bee node without a connected chain backend

[notanatol]

Checklist

• I have read the coding guide
• Bee can boot and do handshakes only with the provided transaction hash
• Bee can retrieve data without a working back-end
• Add the swap flag to packaging
• Review flag name and semantics
• Document the behavior of the bee started with a disabled chain backend (accounting, postage etc)

Description

We want to be able to start a light node with no postage, no overlay verification, no settlements and other chain related functionalities.
This will greatly simplify the onboarding of the Edina person since no blockchain provisioning is needed.

Motivation and context (Optional)

We need to be able to run bee with minimal knowledge/preparation.

https://hackmd.io/5h4BFSDOSPeWnuUd5OR8EA?view

In order to start minimal mode (even from scratch), a transaction must exist at the ETH address that the node started with, and the following configuration parameters must exist in the provided configuration: transaction: (the value of the transaction hash) and block-hash: (which is derived as follows: https://medium.com/@acud/go-ethereum-ethclient-provides-wrong-blockhash-on-xdai-d3da1f25240a)

---

This change is 

[notanatol]

ENS resolver will work as long as we provide a valid configuration param (eg. resolver_options: "https://cloudflare-eth.com/") without a chain backend.

[acud]

Thanks! Looks good and I have some suggestions/questions

[mrekucci]

Reviewed 8 of 15 files at r1.
Reviewable status: 0 of 16 files reviewed, 10 unresolved discussions (waiting on @acud, @aloknerurkar, @istae, @mrekucci, @notanatol, and @ralph-pichler)

---

pkg/node/chain_stub_test.go, line 14 at r4 (raw file):

Previously, acud (acud) wrote…

any particular reason why these compile-time checks are in a _test file?

This is a test of whether a struct implements a certain interface, thus it belongs to tests.

[notanatol]

Reviewable status: 0 of 16 files reviewed, 10 unresolved discussions (waiting on @acud, @aloknerurkar, @istae, @mrekucci, @notanatol, and @ralph-pichler)

---

pkg/p2p/libp2p/parser.go, line 29 at r4 (raw file):

Previously, acud (acud) wrote…

not sure why this is needed? can't we somehow tell libp2p to initialize the handshake service in a way that just never verifies the overlay? or in a sense the handshake service would just plug a different noop parseAck function that would always approve the ack?

this was merely the solution with the smallest footprint changes wise

the alternative - which is passing down a boolean flag to skip verification seems more cumbersome, but we can entertain it

[acud]

pending rebase

Reviewed 1 of 1 files at r9, 1 of 1 files at r10, all commit messages.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @aloknerurkar, @istae, @mrekucci, and @ralph-pichler)

[mrekucci]

Reviewed 1 of 16 files at r1, 2 of 23 files at r11, 24 of 24 files at r13, all commit messages.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @aloknerurkar, @istae, and @ralph-pichler)

---

pkg/debugapi/postage.go, line 195 at r13 (raw file):

	}

	if resp.Stamps == nil {

Not necessary.

---

pkg/node/node.go, line 1040 at r13 (raw file):

}

func isChainEnabled(o *Options, logger logging.Logger) bool {

Consider attaching it to the Options struct.

[notanatol]

Reviewable status: 26 of 27 files reviewed, 3 unresolved discussions (waiting on @aloknerurkar, @istae, @mrekucci, and @ralph-pichler)

---

pkg/debugapi/postage.go, line 195 at r13 (raw file):

Previously, mrekucci wrote…

Not necessary.

removed