[tx-worker] transaction queue functionality updates

[florianlenz]

Problem / Task

We need to monitore transaction's somehow. There are a lot of different transaction's e.g. when we create a nation, send money, join a nation, leave a nation etc (by transaction I mean an ethereum transaction, e.g: https://etherscan.io/tx/0xeaddd283aaee9f197579e0dfd3121f50b647ddd58103ba4636a0f152368aca93).

After a transaction is submitted (e.g. a nation create) we get the transaction hash which look's like this: 0xeaddd283aaee9f197579e0dfd3121f50b647ddd58103ba4636a0f152368aca93. After the transaction is submitted it has the status 'Pending'. Statuses are: Pending, Success or Failed.

The goal is to have a worker that check's transaction's and updated there status AND inform the client (e.g. the mobile client) about the status.

Let's assume we created a nation. After some time the transaction succeed. We should then show an message that say's "Hey, you nation xyz was created". If the transaction fail's we should show "Hi, we failed to create your nation xyz. Please go to the nation tab and submit it again".

The way we display those messages is that we emit an event on the event emitter. E.g.

ee.emit("tx:queue:job:change", {
   heading: "nation.failed_heading",
   body: "nation.failed_body",
   ok: function(){
    //1. delete this job
   //2. process the next job
   }
})

We never use plain text in pangea lib's since i18n is done on the UI. So please use key's like from the example. The ok callback will be called by the UI in order to process the next job in the queue tx. We need to process all job's one by one in order to avoid to many alert's in the UI.

There is a relation between the transaction job and e.g. the nation. We somehow need to know that this job relates to creating a nation in order to show the right message to the client AND customize the ok callback (more about that now). Also important is that we can e.g. fetch a transaction job by it's e.g. nation. So when I join a nation I create an transaction related to that nation. The relation should be bidirectional we use this as our database. It doesn't necessarily has to be a relation forced by the database schema - and it's maybe not even possible. When I send money it's enough to know from which ethereum address it was send. This is an relation as well - tho it's not on a database level.

"ok" behaviours:

create nation

1. update the nation data
2. Remove the job

join nation

1. Mark the nation as joined 2.Remove the job

leave nation

1. make the nation as left
2. Remove the job

send eth

1. Remove the job

Acceptance criteria

• [ ] The above describe thing's are implemented
• [ ] Unit test's exist's for the above described process