gRPC methods for network transactions

[Mirko-von-Leipzig]

See #692 for full context.

Define a new network-transaction service with two methods:

1. Receive new network note (can just be a plain note for now)
2. Receive status update for network transaction (tx_id + Status::Committed | Status::Failed). Consider including block height and error reason respectively.

The new component also needs access to the store and block-producer APIs but only requires one additional store method to retrieve existing network notes on startup.

Consider making this new method a stream - could be good to see how it fits in, considering we want to use it elsewhere potentially.

Somewhat blocked by

• Track network notes in store #696

[bobbinth]

Receive status update for network transaction (tx_id + Status::Committed | Status::Failed). Consider including block height and error reason respectively.

As I mentioned in a comment to one of the other related issues, this endpoint can accept all transactions (tx_id + status is pretty light-weight) and then filter out transactions it doesn't care about internally.

Receive new network note (can just be a plain note for now)

We may also want to add tx_id for every such note (i.e., transaction ID for the transaction which generated this note). Won't be too useful now, but later on, this would allow us to track the node's progress through the mempool.