EIP-7594 - Shorten the new introduced ENR record key (custody_subnet_count).

[nalepae]

Description of the issue:

EIP-7594 introduces a new ENR record: custody_subnet_count.

As highlighted by @wemeetagain in #3644, the maximum encoded size of a node record is 300 bytes. (Source).

For information here is what an ENR entries looks like with this new record:

The custody_subnet_count key by itself consumes 20 bytes, so almost 7% of the total available space in the ENR.

Proposal:
Remplace this key by a shorter one.

[ppopth]

That makes sense. I would say csc (custody subnet count).

[jimmygchen]

csc could be a bit cryptic for those not familiar with the context. I'm leaning towards custnets or custnetcnt as it aligns well with our existing keys attnets and syncnets; and it's also slightly easier to read. What do you think?

[dapplion]

Why not just custody? Do we anticipate any future property that may conflict in that namespace?

[nalepae]

Related:

1. The specification states: custody_subnet_count is a SSZ uint64 (Source).
   Unless we wish to have more than 255 subnets, we waste 7 bytes compared to uint8.
   We could use uint8 or uint16 to be more conservative.
2. Why does this number need to be SSZ encoded? We could use standard big endian integer, as already done with, for example, tcp and udp. (Source)

[wemeetagain]

Why does this number need to be SSZ encoded?

Good point. ENR kvs are already RLP encoded, so that natively handles encoding numbers.

For a positive integer, it is converted to the the shortest byte array whose big-endian interpretation is the integer, and then encoded as a string according to the rules below.

[ppopth]

csc could be a bit cryptic for those not familiar with the context

I think it's cryptic for now, but people can get familiar with it over time.

[hwwhww]

closing via #3772