Executor API cleanup and simplification

[mzabaluev]

Make FinalityMode passed by value like a simple mode selector parameter should be.
Change signatures of methods that don't need to be async
or fallible.

[mzabaluev]

I have further YAGNI feeling about parts of the abstract API:

• Do we really need the dynamic selection with FinalityMode? It's currently unimplemented except for the optimistic mode.
• What do we need the *Executor traits for, as opposed to just providing inherent methods? Future mocking?

[l-monninger]

@mzabaluev FinalityMode is entirely unnecessary (it doesn't actually make sense w.r.t. to the intended design). I thought I had removed it already.

Executor traits are for organization and reuse in a would be SDK.

[mzabaluev]

Executor traits are for organization and reuse in a would be SDK.

In general, I would prefer not introducing traits until there are at least two implementations genuinely needing the abstraction. Especially those transformed by async_trait as they have a runtime cost.

[mzabaluev]

@mzabaluev FinalityMode is entirely unnecessary (it doesn't actually make sense w.r.t. to the intended design). I thought I had removed it already.

I can cut it out in this PR while we are at it, the only problem would be a merge conflict with #58.

[l-monninger]

In general, I would prefer not introducing traits until there are at least two implementations genuinely needing the abstraction. Especially those transformed by async_trait as they have a runtime cost.

I tend to do a fair bit of type-level programming first and like be able to refer to traits for quick understanding on the first pass. So, I'll need to work on that.

I'm trying to use async_trait only where there would be or I anticipate Box<dyn ...> usage. The async_trait vtables also increase binary size, no?

[mzabaluev]

The async_trait vtables also increase binary size, no?

They could, but it's not my first concern.

[l-monninger]

RD