Added revision next for optimizing call/estimate related endpoints

[darrenvechain]

Description

using the best block + 1 when estimating

Type of change

Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

• - Added API unit tests
• - PR is open in the e2e repo, must be merged and then the commit SHA should be updated here

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• New and existing E2E tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules
• I have not added any vulnerable dependencies to my code

[libotony]

Should be mention that the following parameters will be used during the execution: number, timestamp,total score, gas limit, beneficiary and signer, due to the implementation solution, signer will be zero address

[darrenvechain]

beneficiary

You mean something like this @libotony ?

[libotony]

beneficiary

You mean something like this @libotony ?

Was just spreading the info to the team, but this one looks good!

[otherview]

Minor bits that were mostly captured in the offline discussing.

I'm starting to think the next revision should be operational across all of our endpoints, to avoid creating edge cases. It seems to me fair to assume that if someone is requesting the "next" block they know what is that they are receiveing.

With that in mind a superset o GetSummary would probably consolidate the api flows.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 93.68421% with 6 lines in your changes missing coverage. Please review.

Project coverage is 62.66%. Comparing base (bfa83f3) to head (8b559a3).
Report is 1 commits behind head on master.

Files	Patch %	Lines
api/utils/revisions.go	90.32%	3 Missing and 3 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #776      +/-   ##
==========================================
+ Coverage   62.57%   62.66%   +0.09%     
==========================================
  Files         199      199              
  Lines       18153    18196      +43     
==========================================
+ Hits        11359    11403      +44     
+ Misses       5713     5712       -1     
  Partials     1081     1081              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[libotony]

Minor bits that were mostly captured in the offline discussing.

I'm starting to think the next revision should be operational across all of our endpoints, to avoid creating edge cases. It seems to me fair to assume that if someone is requesting the "next" block they know what is that they are receiveing.

With that in mind a superset o GetSummary would probably consolidate the api flows.

There are two parts using revision, Call/Simulate and Get /blocks/{revsion}, next will only apply to the Call/Simulate, the latter won't work with next(I don't see the necessity for returning a mocked next block in get blocks API). The GetSummaryAndState function can be used to simplify the process, but allowNext is essential to control whether the next is supported.

[libotony]

LGTM, two things needs to be checked:

1. @otherview @darrenvechain please confirm that the description in the api doc is sufficient
2. @darrenvechain please confirm that we have next test cases in e2e test

[darrenvechain]

@otherview @darrenvechain please confirm that the description in the api doc is sufficient

Let me add a description to the gas estimation endpoints, encouraging clients to use next Done

@darrenvechain please confirm that we have next test cases in e2e test

I'll get the E2E merged now Done - commit sha updated

[otherview]

@libotony I think this commit might need to be signed 85d11bc

[libotony]

@libotony I think this commit might need to be signed 85d11bc

Done, @darrenvechain had to sign your last 2 commits