spec: add priority to CheckTx ABCI response

[ninjaahhh]

master issue: #154
related code change: tendermint/tendermint#5314

for more context and background information please check the master issue. the relevant part to this specific issue is following:

---

Context

User-defined priorities for blockchain transactions can be useful, e.g. gasPrice in Ethereum blockchain works as a first-price auction mechanism to cope with limited capacity. However in Tendermint, current approach for packing transactions into a block follows a first-in-first-out (FIFO) style which is baked in Tendermint engine and can't be affected by ABCI applications.

To make Tendermint support priority-based transaction processing, two main aspects of current architecture in Tendermint need to be updated: one is on ABCI's interface for accepting a transaction (CheckTx), and another is on Tendermint's mempool design and implementation. This RFC proposes corresponding changes to address these two aspects.

Proposal

Add a new field priority to the ABCI ResponseCheckTx message:

message ResponseCheckTx {
  uint32         code       = 1;
  bytes          data       = 2;
  string         log        = 3;  // nondeterministic
  string         info       = 4;  // nondeterministic
  int64          gas_wanted = 5 [json_name = "gas_wanted"];
  int64          gas_used   = 6 [json_name = "gas_used"];
  repeated Event events     = 7
      [(gogoproto.nullable) = false, (gogoproto.jsontag) = "events,omitempty"];
  string codespace = 8;
  uint64 priority  = 9;
}

Then ABCI developers can add application-specific user-defined priorities for the transactions. This addition is naturally backward-compatible because by default all requests will be returned with 0 priority and on mempool side the process will fallback to FIFO.

...(skip mempool part of changes)

---

this change should be naturally backward-compatible as it won't take any effect until mempool starts to recognize priority. only concern is to inform users that this field is not being used, if we decide to ship a release with this change while leaving out mempool modifications, the latter of which definitely needs more efforts.

[ninjaahhh]

cc @marbar3778

[tac0turtle]

Thank you for opening this issue. I am in favor of making this change even though the corresponding changes in the mempool will not be made till a later date. That being said the change in Tendermint-go would be slated to land after the 0.34 release has been made.

[erikgrinaker]

only concern is to inform users that this field is not being used, if we decide to ship a release with this change while leaving out mempool modifications

I would prefer not including this in the protocol until the implementation is ready, unless there's a compelling reason to - what's the motivation?

[tac0turtle]

I would prefer not including this in the protocol until the implementation is ready, unless there's a compelling reason to - what's the motivation?

How I am viewing it is that we will include this in the spec but the implementation in the tendermint-go repo may land with mempool updates. I do not foresee this change landing in a release till the corresponding work in the mempool has been completed. My wording was incorrect.

[tac0turtle]

this has been added