TxStatus redundant fields

[davidkel]

I came across the verification field in the TxStatus Class definition but could not see it being used outside of connectors setting the property. I think this field is redundant and do not know what it's original purpose was. There may also be other fields in TxStatus that are also redundant

We should remove these fields

[aklenik]

Agree, the TxStatus class needs some fixup. Ideas:

1. Rename the class to TransactionTrace, much more descriptive.
2. Gather every field under a single attribute (kind of a data-oriented approach, but dumping the trace will be a frequent use case).
3. Determine the Caliper-level minimum field requirements: start, finish, status (I think we only use these).
4. Would be nice to allow passing through workload-supplied labels in some form, that can be consumed by TX monitors (Prometheus is a nice example, but also just for general dumping purposes).
5. Caliper doesn't use the detailed error messages in general, only the connectors report them. I think we should collect errors from every possible (multiple) sources, just like now.
6. Think hard on the names of the trace variables :) I'm sure data analysts have some conventions on metric names :)

[davidkel]

I found where the verification field is used and is meant for end user consumption rather than caliper engine consumption. In the docs

`IsVerified():boolean` indicates whether we are sure about the final status of the transaction. 
Unverified(considered failed) transactions could occur, for example, if the adapter loses the connection with 
every Fabric event hub, missing the final status of the transaction.