Identity transactions endpoint

[LINCKODE]

The issue

Archiver has the /identities/{identity}/transfer-transactions endpoint which only returns the transfer transactions of an identity.
There is a need to also return:

1. the mining transactions for an identity
2. the completion status
   We should preferably achieve these results by only calling one endpoint at a time, unlike how we do it for ticks.

Proposals for issue 1

1. New endpoint - Not recommended

We could add new endpoints for fetching the mining transactions.
As an example, we could have another endpoint called /identities/{identity}/mining-transactions.
This endpoint would like /transfer-transactons, with the difference that we return just the mining transactions this time.
Reasons this might not be a good idea:

• API consumer needs to make multiple requests to get a full list of transactions.

2. Return all the data at once - Not recommended

We could rename the /transfer-transactions endpoint to just /transactions and return both mining and transfer transactions at the same time.
This probably isn't the best idea for the following reasons:

• Doesn't allow the API consumer to choose the information he needs.
• May be more bandwidth intensive.

3. Change endpoint to allow for choosing the returned data - Recommended

As with Proposal 2 we could rename the /transfer-transactions to /transactions, the difference being that we could accept an input in the request that determines the output we return.
The input could be either another request parameter, or an object in the body request. Personally I would go with the object.

Pros and cons for input types:

Request parameter:

Pros:

• Can be easily added, as we also accept the min and max tick as request parameters.
• Can use GET method.
  Cons:
• Tedious to assemble the request.
• Tedious to if we want to add more arguments in the future.

Json body object

Pros:

• Way easier to assemble the request, allows for grouping other request arguments together.
• Easy to implement.
• Easy to extend in the future with more arguments.
  Cons:
• The request type will need to be POST.

Request type

Our new will server the purpose of choosing what kind of output the user desires.
For the time being we could have three accepted values:

• TRANSFER
• MINE
• FULL

Based on the input value we will only return the required information.

Proposal for issue 2

We could change the struct definition for the Transaction type to also include the approved status as a boolean.
We could look at how /approved-transactions works to differentiate between approved and not approved transactions.