Enable api_version 2

[arihantkothari]

High Level Overview of Change

Enabling api_version 2 by bumping up apiMaximumSupportedVersion to 2 and fixing AccountInfo tests that were failing as a consequence.

Context of Change

Changing error code leads to breaking changes for error handling in applications relying on those error codes. Hence, all these changes should be upgraded to the next api_version, so that existing users get the existing behaviour, and users who request a higher api_version get the new behaviour.
More context: #4552

Type of Change

• [x ] New feature (non-breaking change which adds functionality)
• [ x] Tests (updated existing tests)

[intelliot]

Discussed today and decided to hold this for 1.13 or later.

[arihantkothari]

Discussed today and decided to hold this for 1.13 or later.

Sorry, I missed this comment. Okay! Thanks for the update @intelliot !

[arihantkothari]

Leaving this comment here (this is from a while back):

Changing apiMaximumSupportedVersion to 2 would result in the failure of the account_info version 1 test because the unit tests typically operate based on apiMaximumSupportedVersion by default. This behavior is due to the calls made within the code flow, specifically Env::do_rpc -> rpcClient -> rpcCmdLineToJson -> insert_api_version, where the api_version is set to RPC::apiMaximumSupportedVersion. It appears that the command line specific function rpcCmdLineToJson is called in order to keep the unit tests aligned with the latest supported API version by default, because the command line exhibits different behavior. The question arises as to whether we should maintain this behavior or not.

Let me be clear here: this PR will still pass all the tests because I added api_version 1 in the test. But the underlying problem STILL exists.

[intelliot]

update: @pwang200 will take a look at this and potentially open a new PR

[arihantkothari]

Closing this PR since #4785 is now open.