refactor(config,protocol,ci): optimize config binding

[317787106]

What does this PR do?

Cleans up config bean binding across CommitteeConfig, NodeConfig, EventConfig, StorageConfig, and VmConfig, removes the dead Overlay class, drops the unused google/api/annotations.proto import, and deletes the stale codecov.yml.

1. CommitteeConfig — allowPBFT / pBFTExpireNum use non-standard casing that JavaBean Introspector cannot derive correctly. Previously these were excluded from ConfigBeanFactory and read field-by-field manually. Now a normalizeNonStandardKeys() helper remaps them to standard camelCase (allowPbft / pbftExpireNum) before binding, so ConfigBeanFactory handles them automatically. The manual getter overrides (getAllowPBFT, getPBFTExpireNum) are replaced by standard Lombok-generated getters.

2. NodeConfig — Three improvements:

   • isOpenFullTcpDisconnect: the is-prefix in the config key conflicts with JavaBean boolean-getter naming. The field is renamed to openFullTcpDisconnect (Lombok auto-generates the isOpenFullTcpDisconnect() getter) and normalizeNonStandardKeys() remaps the legacy config key before binding.
   • discovery.external.ip: previously a standalone externalIP field on NodeConfig read manually after binding. Now it is modelled as DiscoveryConfig.ExternalConfig.ip and auto-bound by ConfigBeanFactory. normalizeNonStandardKeys() normalises both HOCON null and the string sentinel "null" to "" before binding.
   • nativeQueue / topics in EventConfig: removed redundant @Getter(NONE) + hand-written getters; @Setter(NONE) is kept so ConfigBeanFactory skips the keys that require special handling, which are still read explicitly in fromConfig().

3. EventConfig — Replaced a 30-line field-by-field manual binding loop for nativeQueue and topics with ConfigBeanFactory.create() calls. A TOPIC_DEFAULTS fallback config fills optional TopicConfig fields (solidified, ethCompatible, redundancy) so each topic item can be bound uniformly.

4. StorageConfig — Removed @Getter(NONE) + hand-written getters for rawStorageConfig, defaultDbOption, defaultMDbOption, and defaultLDbOption; standard Lombok getters now apply. @Setter(NONE) is retained on all four to prevent ConfigBeanFactory from requiring their keys.

5. VmConfig — constantCallTimeoutMs carried @Setter(AccessLevel.NONE) to block ConfigBeanFactory from touching it; the value was bound manually in postProcess() via vmSection.hasPath() + vmSection.getLong(), and zero was treated as a misconfiguration. This workaround is removed:

   • constantCallTimeoutMs = 0 is added to reference.conf so the key is always present and ConfigBeanFactory binds it automatically.
   • @Setter(AccessLevel.NONE) is dropped; the field becomes a plain Lombok-managed field.
   • The manual hasPath / getLong binding is replaced by a simple range check in postProcess(): negative values and values that overflow microsecond conversion are rejected; zero is accepted as the valid default meaning "share the block-processing deadline".
   • The CONSTANT_CALL_TIMEOUT_MS_KEY and MAX_CONSTANT_CALL_TIMEOUT_MS constants are removed.

6. google/api/annotations.proto — Removed the unused import "google/api/annotations.proto" from api.proto. No RPC method in the file carries an option (google.api.http) annotation, so the import was dead weight that pulled in an unnecessary dependency.

7. codecov.yml — Deleted the stale Codecov configuration file. Codecov integration is no longer active; coverage is handled by JaCoCo + madrapps/jacoco-report in pr-build.yml. The file had already been marked deprecated in a comment but was never removed.

8. Overlay — Deleted the unused Overlay class and its sole test. The corresponding overlay field is removed from CommonParameter.

Why are these changes required?

The previous code used @Getter(lombok.AccessLevel.NONE) + @Setter(lombok.AccessLevel.NONE) + hand-written getter/setter pairs as a workaround for config keys that ConfigBeanFactory could not bind automatically (reserved words, non-standard casing, optional keys). This pattern is verbose, error-prone, and scatters binding logic across fields and fromConfig() bodies. The normalizeNonStandardKeys() pattern and @Setter(NONE)-only approach eliminate the boilerplate while preserving the same runtime behaviour.

This PR has been tested by:

• Unit Tests

Follow up

Extra details

[halibobo1205]

[MUST] Deleting the import google/api/annotations.proto is out of scope for this PR. The change is unrelated to config bean binding — it touches a gRPC service definition, not any of the Config beans or ConfigBeanFactory wiring. Please split it into a separate PR (e.g.
chore(proto): remove unused google.api.annotations import) So it can be reviewed and reverted independently.

[317787106]

This is a little change, only including code clear up. Modified the PR title and description to align with the changes.

[bladehan1]

[NIT] normalizeNonStandardKeys cleanliness: withoutPath + hasPath guard

Two small cleanups apply to both CommitteeConfig.normalizeNonStandardKeys (this file, allowPBFT/pBFTExpireNum) and the sibling NodeConfig.normalizeNonStandardKeys (isOpenFullTcpDisconnect / discovery.external.ip):

1. section.withValue(newKey, ...) adds the new key but does not remove the legacy one. After normalize, both keys coexist in the Config tree. This is harmless for ConfigBeanFactory (only the canonical name binds), but any downstream diagnostic that walks the raw Config (debug dumps, future read paths) will see two competing entries with no documented winner. Chaining .withoutPath(oldPath) after the rename keeps the post-normalize tree canonical.

2. NodeConfig.normalizeNonStandardKeys calls section.getIsNull("discovery.external.ip"), which throws ConfigException.Missing if the path itself is absent (it only returns true when the path exists with a null value). The current code relies on the reference.conf default at external.ip = "" always populating this path. If a user explicitly writes node.discovery = null or node.discovery.external = null to disable a sub-tree, normalize blows up with a stack trace pointing into its internals rather than at the offending config path. A hasPath guard or an explicit javadoc precondition (section must be merged with reference.conf fallback) makes the implicit contract traceable.

Neither is a correctness bug given current reference.conf content; treat as nits.

[bladehan1]

[NIT] Document the new semantics of constantCallTimeoutMs = 0 in the sample config

This PR makes constantCallTimeoutMs = 0 a valid configuration meaning "share the block-processing deadline" — previously the same value was rejected. The sample config still shows the commented hint # constantCallTimeoutMs = 100 without explaining the special semantics of zero. Operators who previously set this to a positive value as a workaround for the old rejection won't know what 0 now implies after the upgrade.

Suggestion: add an inline comment in config.conf clarifying that 0 means "use the block-processing deadline", so the meaning of the default is discoverable from the sample alone.

[ouy95917]

LGTM

[waynercheung]

LGTM