First parameter should be the expected value.

Change-Id: I2941296e38c3245da298cc64aeb5636fbc4b2eb6
Partial-Bug: #1357117

Instead of having code that is some what like the notifier
code we already have, but is duplicated and is slightly different
in the task class just move the code that was in the task class (and
doing similar actions) to instead now use a notifier that is directly
contained in the task base class for internal task triggering of
internal task events.

Breaking change: alters the capabilities of the task to process
notifications itself, most actions now must go through the task
notifier property and instead use that (update_progress still exists
as a common utility method, since it's likely the most common type
of notification that will be used).

Removes the following methods from task base class (as they are
no longer needed with a notifier attribute):

- trigger (replaced with notifier.notify)
- autobind (removed, not replaced, can be created by the user
            of taskflow in a simple manner, without requiring
            functionality in taskflow)
- bind (replaced with notifier.register)
- unbind (replaced with notifier.unregister)
- listeners_iter (replaced with notifier.listeners_iter)

Due to this change we can now also correctly proxy back events from
remote tasks to the engine for correct proxying back to the original
task.

Fixes bug 1370766

Change-Id: Ic9dfef516d72e6e32e71dda30a1cb3522c9e0be6

* H305  imports not grouped correctly
* H307  like imports should be grouped together

Change-Id: If1dd9c89f65ede6959865a885777cb08c263eca0

Move the final logic of the compilation stage (and pre-run) code
into a new engine stage that is devoted to performing post-compile
but pre-run actions. Do the final validation that was being done
in compile() and run() in this stage instead of being split across
those two stages.

Breaking change: any user expecting storage to be ensured after
compilation will have to adjust their code to call prepare (after
which they can continue to expect storage to be ready).

Change-Id: Ie97bc4a795266dda9d7ae8b395bcaadcd1ada737

- Convert the various functions that take a task detail into
  ones that take atom details (since this is now the generic
  type they should take).
- Don't expose the detail type strings as part of the atom
  detail api, leave those as private hidden strings and provide
  conversion functions from string<->class instead.
- Have the logbook objects contain the following new methods
  to reduce the dependence on persistence_utils to do the same.
  - to_dict() which converts the current object into a dict
  - from_dict() which converts the provided dict into a object
  - merge() which merges a incoming objects data with the current
    objects
- Have the persistence backends + storage + action engine use these
  new methods instead of there current usage.
- Don't compare to logbook.RETRY_DETAIL or logbook.TASK_DETAIL since
  python has the isinstance function just use it (ideally we should
  fix the code so that this isn't even needed, usage of isinstance
  means something is not designed/structured right).
- In storage tests we can't assume that failures will be non-lossy
  since under certain backends when a failure is stored information
  about the internally held exc_info is lost, so take this into
  account when testing by using matches() where applicable.

Change-Id: Ie8a274cfd4cb4e64e87c355dc99d466d74a4e82c

Remove line containing

comment - # vim: tabstop=4 shiftwidth=4 softtabstop=4

Change-Id: I7581cc88b8de433d5609ed06c6570b0b45c13573
Closes-Bug:#1229324

Instead of exposing and requiring engines and users to use uuids,
storage now provides more convenient interface that allows to do
anything with task by its name.

Storage is now the entity that maintains name-to-uuid mapping. To
emphasize that, find_by_name method (now unused) was removed from
FlowDetail.

Breaking change: this will break clients that use storage to manipulate
tasks. Clients that use engine.storage only to fetch results with
'fetch' and 'fetch_all' methods (which is the recommended way) are not
affected.

References blueprint task-executor
Co-authored-by: Ivan A. Melnikov <imelnikov@griddynamics.com>
Change-Id: Icbdb745c1ed84c5ac21c6f3a275f32c0b2939d90

Replace assertEquals and assertNotEquals with assertEqual and
assertNotEqual (new rule, H234), and fix indentation.

Change-Id: I86177325dee3aa00af5df8b3085acd478994ee34

Before this change we used to loose any progress details set by task
when it was updating its progress when task state was changed from
RUNNING to SUCCESS (and thus progress forced to 1.0). This commit
fixes this, so that when progress is updated from the engine latest
progress details are preserved.

Breaking change: to allow details to be associated with progress
value they were set for we save progress and then return progress
value with details.

Change-Id: Ic90e61ee3dcf62731696a0f10134bc448e7d6384

Previously to run a flow client code had to put together the flow,
an engine, logbook, flowdetail, and storage backend. This commit
adds two helper functions, run() and load(), so that simplest usecase
now looks like

    taskflow.engines.run(flow)

Client code may also provide configuration for storage and engine if
needed, but if not needed it just works with defaults.

Engines are loaded via stevedore, as drivers in 'taskflow.engines'
backend. Now three entry points are defined in that namespace:
- 'default', for SingleThreadedActionEngine, used by default;
- 'serial', as another synonym for SingleThreadedActionEngine;
- 'parallel', for MultiThreadedActionEngine.

Closes-bug: #1224726
Change-Id: I7f4cb5c8ff7f5f12831ddd0952c202d2fd8cd6ef