Identify `yapapi` bits that should be replaced by `golem-core` usage

[approxit]

Regardless of work in golemfactory/golem-core-python#57, we can start work on yapapi side regarding golem-core integration. But first, we need to actually identify which parts of yapapi is/should be handled by lower level library. As we still don't know if that two libraries would be merged or not, we know in both cases we need that kind of separation.

Todo:

• [x] Prepare a list of yapapi bits that golem-core should be responsible for (regardless of golemfactory/golem-core-python#57) and should be refactored to use golem-core implementation

[approxit]

Additional questions:

• What to do about the yapapi event system relates to different way how to golem-core events?
• What to do about possible goth tests, which is tightly bound (hardcoded) to yapapi event logs, which will be different with golem-core?

[lucekdudek]

Initial research finding:

Things that should be replaced:

• Payload
• DemandBuilder
• GFTP provider and storage abstractions. Keep webdev storage but use abstraction from golem-core
• rest module with golem-core's low module so yappai dosen't use ya_ libs directly
• DEFAULT_DRIVER, DEFAULT_NETWORK, DEFAULT_SUBNET
• _YagnaDatetimeFormatter
• make yapapi's events not ued and remove them (are goth tests using those event?)
• make worker funciton use golem core's batches: remake Executor into a adapter so it uses golem core's batches