refactor: bytes_i_to_uint256

[obatirou]

Time spent on this PR:

Pull request type

Please check the type of change your PR introduces:

• Bugfix
• Feature
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no api changes)
• Build related changes
• Documentation content changes
• Other (please describe):

What is the current behavior?

Resolves #897

What is the new behavior?

• rename bytes_i_to_uint256 to bytes_big_endian_to_uint256
• simplify boolean condition for is_bytes_len_16_bytes_or_less
• follow conventions by having bytes_len before bytes
• rename compute_half_uint256 to compute_half_uint256_from_bytes
• improved readability for pow256_rev
• use pow256_rev instead of pow from starkware lib: from 2419 to 1261 steps

With pow from starkware lib

With pow256_rev

---

This change is 

[enitrat]

hi @obatirou thanks for the PR, it's normal that CI is failing given that the runner was recently updated for the Cancun fork, but not the main branch of this repo! will take a look tomorrow

[ClementWalter]

please remove the _big_endian in the function name as in solidity this is the default behavior (ie. that uint256(bytes32) is big endian actually)

[enitrat]

please remove the _big_endian in the function name as in solidity this is the default behavior (ie. that uint256(bytes32) is big endian actually)

@ClementWalter In SSJ there are occurences where we need to use conversions from little-endian bytes. I think it's for precompiles though, so it might not be a direct concern here. But I still think it's good to have it :)

[ClementWalter]

please remove the _big_endian in the function name as in solidity this is the default behavior (ie. that uint256(bytes32) is big endian actually)

@ClementWalter In SSJ there are occurences where we need to use conversions from little-endian bytes. I think it's for precompiles though, so it might not be a direct concern here. But I still think it's good to have it :)

there are some places where we specifically put _little_ but by default without any precision I think that it's obvious that it's end. It's the solidity/yul behavior, it's part of our EVM ubiquitous languages

[ClementWalter]

can you run once again the profiling to check the final steps count?

[ClementWalter]

final results, ie steps down from 2425 to 601, ie x4 improvmenet