Proposal: generic uint_to_bytes

[hwwhww]

Issue

An alternative to #1746 int_to_bytes and compute_shuffled_index part.

1. [Typing presentation bug] Status-quo int_to_bytes expects uint64 as the input. But actually we were passing Python int to it in some cases.
2. Part of Apply strict uint64 casting #1746. Open a new PR to discuss this phase 0 change proposal for decreasing ambiguity. IMHO this PR is neater than Apply strict uint64 casting #1746's casting.

Proposed solution

1. To make it more explicit, rename int_to_bytes to uint_to_bytes and enforce the input of uint_to_bytes to be SSZ uint type.
2. Encode the uint object by its length in bytes. i.e., encode uint8 to 1-byte output and uint64 to 8-byte output.
3. To avoid exposing SSZ APIs, describe uint_to_bytes in prose instead of in code. Similar to hash_tree_root.
4. To make it more explicit, rename bytes_to_int to bytes_to_uint64.

Note: It's a refactoring change of the current spec and it should not change the consensus logic.

[djrtwo]

I like this approach

[djrtwo]

Doing an explicit cast to uint8 right here might result in better readability and fewer client errors

[djrtwo]

mainly because current_round being 8-bit is an exception to our general 64-bit rule and easy to overlook

[djrtwo]

open to other's thoughts on this

[protolambda]

Please review the type-infer branch (based on #1746), it handles many of the more "obvious" type inferences, to keep the spec clean. For compute_shuffled_index it doesn't involve as many casts anymore, by following a simple set of rules to keep the output size the same as the input size. And it fixes + catches new things.