chore: regular block creation time (5s)

[r3v4s]

Thanks to @jaekwon's comment
I've modified some configurations, and now gno creates blocks regularly (every 5 seconds) regardless of the creation of new transactions.

It seems that function WaitForTxs() must return false in order to create blocks regularly.

gno/tm2/pkg/bft/consensus/config/config.go

Lines 79 to 81 in 5d32c39

	func (cfg *ConsensusConfig) WaitForTxs() bool {
	return !cfg.CreateEmptyBlocks || cfg.CreateEmptyBlocksInterval > 0
	}

gno/tm2/pkg/bft/consensus/state.go

Lines 838 to 849 in 5d32c39

	waitForTxs := cs.config.WaitForTxs() && round == 0 && !cs.needProofBlock(height)
	if waitForTxs {
	if cs.config.CreateEmptyBlocksInterval > 0 {
	cs.scheduleTimeout(cs.config.CreateEmptyBlocksInterval, height, round,
	cstypes.RoundStepNewRound)
	} else {
	// wait until mempool pings us.
	}
	} else {
	cs.enterPropose(height, round)
	}
	}

BTW, I don't see any codes in #L844 for // wait until mempool pings us.

At least the problem from issue #863 can be solved in this way. However, I'm not entirely sure about the purpose of CreateEmptyBlocksInterval.

---

@moul
Do you think it's better to edit the .toml file as you did in #899?
Also, do you have any estimated time for test4 (or test4-m1 for multi-node)? If the next testnet resolves the block time issue, the Onbloc team will be happy to work on the multinode testnet initiative #9 META Multinode Testnet Initiative

Contributors Checklist

• Added new tests, or not needed, or not feasible
• Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory
• Updated the official documentation or not needed
• No breaking changes were made, or a BREAKING CHANGE: xxx message was included in the description
• Added references to related issues and PRs
• Provided any useful hints for running manual tests
• Added new benchmarks to generated graphs, if any. More info here.

Maintainers Checklist

• Checked that the author followed the guidelines in CONTRIBUTING.md
• Checked the conventional-commit (especially PR title and verb, presence of BREAKING CHANGE: in the body)
• Ensured that this PR is not a significant change or confirmed that the review/consideration process was appropriate for the change

[moul]

Lets start with a test on staging, by updating the .toml, and then eventually make it the default also for dev.

[moul]

Merged, should be auto-deployed in ~1h if no problem.