x/sync -- use for sending Range Proofs

[danlaine]

Follow up to #1472. Will make a follow up PR atop this one for change proofs.

Why this should be merged

We're moving x/sync networking to use proto.

How this works

• Regenerate proto files
• Remove EncodeRangeProof
• Remove DecodeRangeProof

How this was tested

New UT

[danlaine]

added so that we can assert this error in a sync test

[danlaine]

Changed so that the ValueOrHash can be None, whereas previously it was always Some

[StephenButtolph]

I think this change introduces a number of panic vulns. ex:

func TestProofNodeUnmarshalProtoNilMaybeBytes(t *testing.T) {
	rand := rand.New(rand.NewSource(1337)) // #nosec G404

	node := newRandomProofNode(rand)
	protoNode := node.ToProto()

	protoNode.ValueOrHash = nil

	protoNodeBytes, err := proto.Marshal(protoNode)
	require.NoError(t, err)

	var unmarshalledProtoNode syncpb.ProofNode
	err = proto.Unmarshal(protoNodeBytes, &unmarshalledProtoNode)
	require.NoError(t, err)

	var unmarshaledNode ProofNode
	err = unmarshaledNode.UnmarshalProto(protoNode) // Panics
	require.NoError(t, err)
}

I believe there are similar concerns with the Range Proofs

[danlaine]

I think this is adequately handled now

[xinifinity]

This is enforced here, right?

[danlaine]

Changed this to uint64 (proto uses varints so this doesn't actually make the message larger on the wire.)

This actually isn't really enforced. Like, our assumption here is that there is never a key whose length is more than half of math.MaxUint64. We could add checks in the code to ensure this is upheld but I talked with @StephenButtolph and he (and I) are OK with omitting those since, well, that's a really big number.

[xinifinity]

nit: make import alphabetically ordered

[danlaine]

For avalanchego we order our imports as follows:

• standard library imports
• non-standard-library imports (separated by spaces)
• imports from avalanchego

I've adhered to that here, but I re-ordered the non-standard-library imports to be alphabetical

[StephenButtolph]

lgtm

[StephenButtolph]

For future reference: https://protobuf.dev/programming-guides/proto3/#default

When a message is parsed, if the encoded message does not contain a particular singular element, the corresponding field in the parsed object is set to the default value for that field. These defaults are type-specific:

• ...
• For message fields, the field is not set. Its exact value is language-dependent. See the generated code guide for details.

Which means we are enforcing that the message is specified - even if the inner fields are fully the zero value.

This is probably slightly inefficient w.r.t. network bandwidth. But I don't have strong opinions on it