fix(modshare): start peer manager after Syncer

[Wondertan]

Fixes panic:

panic: invalid type received %!s(<nil>)

goroutine 602 [running]:
github.com/celestiaorg/go-header/p2p.(*subscription[...]).NextHeader(0x103fbeaa0?, {0x103fdcd50, 0x14000723310?})
	/Users/rford/go/pkg/mod/github.com/celestiaorg/go-header@v0.3.1/p2p/subscription.go:44 +0x2ac
github.com/celestiaorg/celestia-node/share/p2p/peers.(*Manager).subscribeHeader(0x1400158c960, {0x103fdcd50, 0x14000723310}, {0x103fbe928?, 0x14000676250?})
	/Users/rford/Programming/Celestia/celestia-node/share/p2p/peers/manager.go:299 +0xc0
created by github.com/celestiaorg/celestia-node/share/p2p/peers.(*Manager).Start in goroutine 262
	/Users/rford/Programming/Celestia/celestia-node/share/p2p/peers/manager.go:180 +0x410

[Wondertan]

Alternatively, we can avoid panicking there and just return an error. This will also work but has a downside that all the headers before the Verifier is registered will be dismissed, which is OK imo and up for discussion.

[codecov-commenter]

Codecov Report

Merging #2677 (803de4b) into main (b1a6349) will decrease coverage by 0.05%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main    #2677      +/-   ##
==========================================
- Coverage   51.39%   51.34%   -0.05%     
==========================================
  Files         159      159              
  Lines       10677    10680       +3     
==========================================
- Hits         5487     5484       -3     
- Misses       4714     4720       +6     
  Partials      476      476              

Files Changed	Coverage Δ
nodebuilder/share/module.go	0.00% <0.00%> (ø)

... and 4 files with indirect coverage changes

📢 Have feedback on the report? Share it here.

[renaynay]

In the past, we've done InitStore type which is annoying and bulky - and I even prefer this with a comment.

I wonder if we can do the same for InitStore

[Wondertan]

@renaynay, iirc, we couldn't make it this way in InitStore due to some other blocker.

[renaynay]

@Wondertan #2678

[distractedm1nd]

I don't really understand how this ensures that? I thought the lifecycles are only started after everything is provided

[Wondertan]

I don't really understand how this ensures that? I thought the lifecycles are only started after everything is provided

@distractedm1nd, exactly, and lifecycles also started in the dependency graph order, so now it's guaranteed that Syncer will start before PeerMan.
I've tested that on the reconstruction test that consistently fails locally. With this fix, its not