Audit all endpoints for differences from protobuf

[peterargue]

Review all endpoints and flag and differences in the request or response objects in the protobuf and SDK implementation.

Once we have a list, let's create issues to update all of the client handlers that should be updated.

[illia-malachyn]

Endpoints that look fine:

Ping - OK
GetNetworkParameters - OK
GetTransactionsByBlockID - OK
GetAccount/GetAccountAtLatestBlock/GetAccountAtBlockHeight - OK
ExecuteScriptAtLatestBlock/ExecuteScriptAtBlockID/ExecuteScriptAtBlockHeight - OK
GetLatestProtocolStateSnapshot - OK
GetExecutionResultForBlockID - OK (we don't return 1 field but it's marked as deprecated)
GetExecutionDataByBlockID - OK
SubscribeExecutionData (and similar) - OK
SubscribeEvents (and similar) - OK

Endpoints that return less info but look fine:

GetLatestBlockHeader/GetBlockHeaderByID/GetBlockHeaderByHeight

• we return significantly less info on the SDK side but it looks fine

GetLatestBlock/GetBlockByID/GetBlockByHeight

• GetLatestBlockRequest request omits full_block_response field
• BlockResponse contains significantly less info on the SDK side but looks fine
• BlockHeader & BlockPayload contain less info but look fine

GetCollection (and similar)

• response: we don't return collection ID, but I guess we use an array index for this instead ([]Collections)

GetTransaction

• block_id, collection_id are not used in a request but it looks fine

GetTransactionResult

• block_id, collection_id are not used in a request but it looks fine
• TransactionResulthas less info but looks fine

GetTransactionResultByIndex/GetTransactionResultsByBlockID

• TransactionResult has less info but looks fine

SendTransaction

• SendTransactionResponse model has an ID field. We don't use it on the SDK side and return error. However, it's totally fine as client can calculate id themselves by using tx.ID() method.

GetEventsForHeightRange - OK

• though we return 1 more field Value cadence.Value in events []Events. It's fine. We do this decoding to cadence value for clients.

Endpoints that are questionable:

GetNodeVersionInfo

• we don't return CompatibleRange compatible_range field on the SDK side.

[nvdtf]

Given these endpoints have been in use by developers for some time, I would not prioritize any change unless explicitly asked by a developer. This being said, delivering breaking changes to make the AN API in the SDK fully equivalent seems fine too, given we have enough engineering capacity to tackle.