Analyze and improve performance of readonly contract calls

[rdeioris]

This issue is the "central-hub" for gathering informations about the current state of readonly contract-calls and how we can improve their performance.

There have been various reports of bad performance when calling readonly functions, with extreme cases where builders have been force to workarounds (included accessing the MARF directly).

As an initial step those are the measurements of a simple readonly call over a very simple function accessing the chainstate:

(define-read-only (chainstate-test)
        (get-block-info? header-hash u0)
)

A call through HTTP (/v2/contracts/call-read/...) takes around 1.5 milliseconds on the testing system.

The profiled calls to reach the results are the following (note: some of them, like the http parsing ones, have been removed from the table)

• cost tracking: (using LimitedCostTracker::Limited) 850 microseconds (600 nanoseconds, yes NANOseconds, using the LimitedCostTracker::Free)
• getting the clarity version: 120 microseconds (this requires database access plus analysis of the contract, we could do this during deploy and store the version value)
• computing contract size: 150 microseconds (this is called in inner_execute_contract and it is part of the cost tracking)
• runtime_cost: 900 nanoseconds (for ClarityCostFunction::LoadContract, basically irrelevant, but part of the cost tracker process)
• eval + apply + special_get_block_info: 10 microseconds (they looks efficient, but we need to better profile sqlite access on high levels of concurrency and measure the clarity vm efficiency when dealing with deeper stacks)

Notes:

• It is clear that cost tracking plays a huge role here, given that we can rely on the recent max_execution_time as a security measure, we could investigate better about having a "free cost" call (check feat(api): add a cost_tracker option to callreadonly rpc specifying the CostTracker to use for evaluation #5828)
• Reducing the requirements of analysis by pre-doing them during the contract-deploy could be another strategy