refactor: separate client in more stand-alone components

[tomyrd]

I don't have any well-formed ideas on this, but the general idea was to provide more "stand-alone" components that the user would be able to combine in various ways that we cannot currently anticipate.
For example, one such component could be StateSync component. We'd instantiate it with some set of parameters (e.g., note tags, nullifiers, etc. we are interested in) as well as some sub-components (e.g., RPC to use to make requests to the network). Then, we'd call sync() on it and it would run the sync and give us all the relevant data, but without saving it to the store. So, basically, StateSync becomes an independent component that can be used even outside of the Client. Then users would be able to compose it with the Store component as they see fit.

Originally posted by @bobbinth in #467 (comment)

[tomyrd]

I've been thinking a bit on this. I feel like the general approach would be to identify big/complex parts inside the client and look to move them to their own components that do the processing but don't change the client's state, this could be done separately.

Some important/complex processes in the client I identified are:

• Note creation, specifically note importing but could be joined with deriving note records form their miden_objects counterparts like Note and InputNote/OutputNote. This component could be composed to get information on all note records created.
• State synchronization, like it's mentioned in the original comment. This component would deal with making the rpc request, checking block relevance, mmr changes, updating notes' and accounts' states (just getting the new states, without applying them to the store). The part previous to the request (i.e. getting the relevant information for the sync) might also be a possible component.
• Transaction creation, this would entail the TransactionRequest to TransactionResult process. Validating the transaction, getting the relevant elements from the store, injecting fpi information, executing the transaction and building the final result.

I'm planning on creating a branch with these possible components, just moving the code around and seeing what the interfaces should be but feel free to mention if you agree with this separation or if we should head in a different direction (maybe having more smaller components).

[bobbinth]

I'm planning on creating a branch with these possible components, just moving the code around and seeing what the interfaces should be but feel free to mention if you agree with this separation or if we should head in a different direction (maybe having more smaller components).

Makes sense. I would probably implement these one component at a time and maybe start with the state synchronization one. It can be done in the PR, but if you'd like to share a sketch here - that's fine too.