[wip] first pass at refactoring

[mpenet]

As marked on the title it's a work in progress, I just moved things around for now and try to clean up some things like imports. No radical change to the way async or errors are handled just yet for instance.

I am not 100% happy with the file structure but it's getting there.

• [x] Protocols are separated from the impl for every context, prefixed with - to allow for later spec'ization potentially among other things.
• [x] Testing code is moved in... tests.
• [x] storage impementations still need to be moved
• [x] print methods code is still scattered a bit everywhere too.
• [x] re-run bench to make sure we're still have reasonable perf.

The tests pass on core/messaging but I didn't test things in detail just yet.

related to #4

Still a lot to do, but I couldn't help it.

[mpenet]

still [wip]

Some observations so far:

• it adds tons of overhead from 10x to 3x worse depending on the ops according to bench, which is quite bad but at the same time we expected a slowdown given we just added coordination overhead for now.
• we still (have to) do a lot of operations sequentially, inside go blocks, so we do not gain anything from parallelism in these cases. We have actually very few opportunities to parallelize anything since we quite often either depend on previous steps to continue tasks, sorted values or the overhead of coordination to "gather" results in order trumps potential gains. That all depends on ratio unresolved/resolved nodes we'll encounter, which depends quite a lot on the context/usage.
• bench is all in-memory, so potential slow IO with a (remote) backend does not show
• I need to bench with master in async mode, I might have introduced slowdowns un-intentionally too.

[whilo]

I see, yes I remember that async was quite a bit slower when I introduced it. I remember something around a factor 2-4x slower in the insert and delete benchmarks.

[mpenet]

yes I somewhat closed to gap and reached similar numbers as yours. The sync version is equivalent to master.

I also have a branch with promesa instead of core.async, I wanted to give it a try and see if there's a potential difference in performance, but no, it's actually worse and promesa had to be monkey-patched to be usable as completablefuture.

[whilo]

very interesting. hmm, so do you think we have to stick to sync and async version?

[mpenet]

Yes I think it would be wiser.

The pr cleans up quite a bit of the branching for platforms & io so it's already a bit better in terms of readability imho.

Let me know what you think of it, as I took a few liberties along the way. It's also not complete as cljs build is broken right now, but it's prolly just minor adjustments.

[whilo]

I am ok with merging this as is and try to move on to further refactoring and importantly for the rebase towards allowing reverse iterators for datahike.

[whilo]

Does that make sense to you?

[mpenet]

Sure! I am traveling atm so I can't look into it. You very likely need to make sure all tests pass, I think it should be in good shape but I might have missed something with my last modifications.

[whilo]

It seems that flush-tree returns a channel in channel. This breaks the simple konserve tests. I am not sure how this could went wrong. We do not need to implement the reverse iterator for the datahike rebase though, so I would wait until you have time to go through this PR. How is your schedule for the next weeks?

[mpenet]

Odd. I will have a look early next week, it's probably something quite simple.

[whilo]

:+1: Yes, I think so as well. I just haven't had enough time to investigate it yet.

[mpenet]

@whilo It should be fixed now