Rename CollectionRetrievalResult field 'batch' to 'transaction_list'

[arun-koshy]

Fixes Issue#529

[arun-koshy]

Just to clarify BlockWaiter returns

pub struct GetBlocksResponse {
    pub blocks: Vec<BlockResult<GetBlockResponse>>,
}

pub struct GetBlockResponse {
    pub id: CertificateDigest,
    pub batches: Vec<BatchMessage>,
}

pub struct BatchMessage {
    // TODO: revisit including the id here [see #188]
    pub id: BatchDigest,
    pub transactions: Batch,
}

pub struct Batch(pub Vec<Transaction>);

pub type Transaction = Vec<u8>;

Currently we are just placing the batches in GetBlockResponse into a proto as follows

message CollectionRetrievalResult {
    oneof retrieval_result {
        BatchMessage batch = 1;
        CollectionError error = 2;
    }
}

message BatchMessage {
    BatchDigest id = 1;
    Batch transactions = 2;
}

message Batch {
    repeated Transaction transaction = 1;
}

message Transaction {
    bytes transaction = 1;
}

But if I am understanding @huitseeker and @akichidis correctly we want to wrap the batches in the original Collection and remove BatchMessage to simplify the type tree i.e.

message CollectionRetrievalResult {
    oneof retrieval_result {
        Collection collection = 1;
        CollectionError error = 2;
    }
}

message Collection {
    CertificateDigest id = 1;
    repeated Batch batches = 2;
}

message Batch {
    BatchDigest id = 1;
    repeated Transaction transactions = 2;
}

message Transaction {
    bytes transaction = 1;
}

[akichidis]

I think there are two topics:

1. conceptually, do we expose the internal batching structure when we retrieve a collection? That's certainly something we can revisit, but if so, perhaps not in PR comments.
2. the actual types we expose at the moment in a CollectionRetrievalResult should have nothing to do with a BatchDigest (they are not comparable to any BatchDigest in the system) or with a BatchMessage (the are the concatenation of several batches, and thus not a batch).

I've left comments in this direction in the PR.

@huitseeker regarding topic (1) yes I believe we should revisit this endpoint. More specifically in the aspects of:

• returned items / structure
• errors
• naming

Thus I don't recommend doing any renaming/changes spend effort on it, and redesign it. I agree, let's not use the PR, we can setup a discussion for this.