feat!: support coordinated v2 upgrade with flag

[cmwaters]

Overview

As discussed, given no pre-existing coordinating mechanism (i.e. signalling), v2 will have to work differently to future upgrades. Namely, nodes will run start with an upgrade-height flag. At the height before that in EndBlock, the protocol version will be updated and cometbft will receive the new v2 app version. There will be no state migrations. The block at the following height will be v2 and validators will begin validating and executing accordingly.

I plan on following up with this with a e2e test upgrading from v1.x to main.

Checklist

• New and updated code has appropriate documentation
• New and updated code has new and/or updated testing
• Required CI checks are passing
• Visual proof for any user facing features like CLI or documentation updates
• Linked issues closed with keywords

[codecov-commenter]

Codecov Report

Merging #2803 (422cc9d) into main (75f9393) will decrease coverage by 0.64%.
The diff coverage is 28.57%.

@@            Coverage Diff             @@
##             main    #2803      +/-   ##
==========================================
- Coverage   19.80%   19.17%   -0.64%     
==========================================
  Files         144      142       -2     
  Lines       17398    17282     -116     
==========================================
- Hits         3446     3313     -133     
- Misses      13631    13667      +36     
+ Partials      321      302      -19     

Files	Coverage Δ
app/prepare_proposal.go	0.00% <ø> (ø)
app/process_proposal.go	0.00% <ø> (ø)
test/tokenfilter/setup.go	100.00% <100.00%> (ø)
x/upgrade/keeper.go	23.68% <100.00%> (+3.17%)	⬆️
x/upgrade/types.go	24.13% <ø> (-59.00%)	⬇️
app/app.go	4.41% <0.00%> (+0.05%)	⬆️
cmd/celestia-appd/cmd/root.go	0.00% <0.00%> (ø)

... and 1 file with indirect coverage changes

[rootulp]

Overall LGTM and seems a bit easier to maintain than a map of upgradeSchedules. My only feedback is around clarifying (either via godoc or flag rename) that the --upgrade-height flag is only applicable to the v1 to v2 upgrade.

[evan-forbes]

👍

[evan-forbes]

this still LGTM, but out of curiosity, did we add a commit here and github is still letting us merge without getting more approves?

[rootulp]

I think the approvals didn't get dismissed b/c this PR targets a feature branch cal/minor... that doesn't have this setting:

[evan-forbes]

ahh I see thanks. assumed it was towards main

[cmwaters]

I assume when it switches, it will dismiss the review

The base branch was changed.

[rootulp]

Still LGTM