Reduce duplication in Smart Contract Service

[tinker-michaelj]

Related issue(s):

• Closes Replace ScImpl with a standard ContractsController  #74, closes Refactor ScImpl#getTxRecordByContractID as an AnswerService in terms of HederaContracts #76, closes Refactor ScImpl#contractGetInfo as an AnswerService in terms of HederaContracts  #77, closes Refactor ScImpl#contractGetBytecode as an AnswerService in terms of HederaContracts #78
• Addresses Refactor ScImpl#contractCallLocal as an AnswerService in terms of HederaContracts  #79, Refactor SCRH#contractCall as a TransitionLogic in terms of HederaContracts  #81, Refactor SCRH#updateContract as a TransitionLogic in terms of HederaContracts #82, Refactor SCRH#deleteContract as a TransitionLogic in terms of HederaContracts #83, Refactor SCRH#createContract as a TransitionLogic in terms of HederaContracts  #84 but does not close them.
• Addresses Rationalize based on Platform properties taxonomy :: Node-local/Network and Static/Dynamic #104 (completes migration of all global/dynamic properties) but does not close it.

Summary of the change:

• Replace legacy SmartContractServiceImpl with a ContractsController that delegates queries to AnswerService implementations, and uses the standard submission flow for transactions.
• Adapt each SmartContractRequestHandler method as a TransitionLogic; refactor all prechecks as TransitionLogic.syntaxCheck implementations, hence removing duplication between legacy handlers and TransactionValidationUtils/AwareProcessLogic components.
• Also adapt the FreezeHandler as a TransitionLogic to eliminate legacy record mapping from AwareProcessLogic.
• Refactor all contract-related global/dynamic properties.

External impacts:

• The required node payment for a ContractCallLocal query can be slightly higher now, since the prior code computed gas and non-gas fees separately (hence rounding down twice in two separate tinycent -> tinybar conversions); the refactored code only rounds down once.

[codecov]

Codecov Report

Merging #908 (a8ae3fc) into master (c4c1eef) will increase coverage by 2.08%.
The diff coverage is 83.61%.

@@             Coverage Diff              @@
##             master     #908      +/-   ##
============================================
+ Coverage     82.17%   84.25%   +2.08%     
- Complexity     4690     4761      +71     
============================================
  Files           402      410       +8     
  Lines         14933    14761     -172     
  Branches       1590     1502      -88     
============================================
+ Hits          12271    12437     +166     
+ Misses         2187     1899     -288     
+ Partials        475      425      -50     

Impacted Files	Coverage Δ	Complexity Δ
...ontext/properties/StandardizedPropertySources.java	98.24% <ø> (-0.06%)	19.00 <0.00> (ø)
...edera/services/legacy/config/PropertiesLoader.java	57.50% <ø> (+4.16%)	8.00 <0.00> (ø)
.../hedera/services/legacy/handler/FreezeHandler.java	82.30% <ø> (ø)	14.00 <0.00> (ø)
...es/legacy/handler/SmartContractRequestHandler.java	3.56% <0.00%> (+0.08%)	2.00 <0.00> (ø)
...ra/services/legacy/logic/ApplicationConstants.java	95.83% <ø> (-0.72%)	1.00 <0.00> (ø)
...vices/legacy/services/state/AwareProcessLogic.java	15.03% <0.00%> (-22.41%)	7.00 <0.00> (-17.00)
...vices/legacy/utils/TransactionValidationUtils.java	62.50% <ø> (+11.45%)	10.00 <0.00> (-14.00)	⬆️
...era/services/state/merkle/MerkleAccountTokens.java	89.65% <ø> (ø)	44.00 <0.00> (ø)
.../com/hedera/services/state/merkle/MerkleToken.java	87.86% <ø> (ø)	60.00 <0.00> (ø)
...com/hedera/services/stats/ServicesStatsConfig.java	50.00% <ø> (ø)	1.00 <0.00> (ø)
... and 41 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c4c1eef...a8ae3fc. Read the comment docs.

[ljianghedera]

Should this line be return -cryptoTransferNet;?

[tinker-michaelj]

For a CryptoTransfer, we can directly compute the affect on the payer (for example, if payer 0.0.1234 sends 1_000 tinybar, then the transferList will have an AccountAmount entry like { account: 0.0.1234, amount: -1_000 }...so then we getcryptoTransferNet=-1000 directly).

For the other operation types, we need to multiply a quantity by -1 to get the cryptoTransferNet, since in these cases there is some amount (gas, an initialBalance, or a sent amount) that will be deducted from the payer.

[ljianghedera]

Yeah. I realized that all amount in transfer list from this payer is negative. Thanks for the clarification.

[ljianghedera]

LGTM overall.

[ljianghedera]

@tinker-michaelj thanks for addressing these minot issues. I think it's good to merge into master.

[qnswirlds]

The changes look good to me in general. The test coverage increased significantly due to the refactoring, so great work! As pointed out by Codecov, there are some new lines that are not covered by tests, but those could definitely improved in a future PR. We still have all the smart contract integration tests from test-clients that were passing to give us confidence for this merge.

[qnswirlds]

Re-approve for the resolved merge conflicts and fix for MerkleAccountTokens deserialization.