Include reason for `BadApiResponse` in `PromoteTransactionCommand`

[lzpap]

PromoteTransactionCommand calls CheckConsistencyCommand internally to determine if the tail transaction can be promoted or not.
When status in CC response is False, BadApiResponse is raised which should contain the info field from CC response as well. This is the reason returned by the node.

[todofixthis]

The response payload should already be included in the context attribute of the exception:
https://github.com/iotaledger/iota.py/blob/master/iota/adapter/__init__.py#L484-L496

[lzpap]

@todofixthis I'm talking about this exception:
https://github.com/iotaledger/iota.py/blob/9416068a13f12d09b27dd9522f5885ff0eaae25c/iota/commands/extended/promote_transaction.py#L38-L43
The response from the node should be alright from the adapter's perspective, it it should contain status, info and duration fields.

Btw a question: how are exceptions raised with with_context should be handled in application code? What is the best practice to get also the context and not just the error message written to the output?

[todofixthis]

with_context is meant to be a way for developers to include other relevant information with the exception that is more lightweight than trawling through the stack frames.

Including the information in the exception message is often convenient, but sometimes not (e.g., the context for an exception might be a bundle, and that means a VERY long exception message!).

Attaching additional information to the exception requires a bit of extra effort on the application developer's part, but it opens up additional options for troubleshooting.

E.g.,:

try:
  pt_response = api.promote_transaction(...)
except BadApiResponse as e:
  # Production scenario:
  # Log exception details to database, log, DLQ, etc. for forensics.
  log_to_database(e.message, e.context, # etc.

  # Development scenario:
  # Display context information with the exception, to make it easier to debug the issue.
  pprint(e.context)
  raise

In particular, I used this technique on a previous project that logged exceptions (and their context values) to a database, which proved invaluable for diagnosing errors that occurred on production.

Additionally, for developers who are not familiar with PyOTA internals, this gives them a way to inspect/debug values that are relevant to the exception, in a way that doesn't require them to edit/debug 3rd-party code.

[lzpap]

Thanks @todofixthis for the explanation, I'm gonna include it in for #310.