refactor: improve note state handling in SqliteStore

[tomyrd]

With the increasing complexity of possible note states we should refactor the SqliteStore struct and SQL tables to better handle them.

Some examples of current values that determine the state of a note:

• status
• ignored
• proof_state (Proximately)

Based on the post by @bobbinth in #485 (comment)

[tomyrd]

This could be done alongside #376

[bobbinth]

One of the things that I think would be awesome to do is to map out all states an input note can be in and see if the way we capture these state in the table makes sense.

For example, we have Committed notes. These must always have an inclusion proof, but the proof may be verified or not verified. So, we really have "verified committed" notes and "unverified committed" notes.

Similarly, Processing notes may have verified inclusion proofs or may have no inclusions proofs - but they cannot have unverified inclusion proofs (I think).

There are probably a dozen (or maybe more) different variations of these and I think it has become difficult to make sense of different combinations. So, I think if we can come up with a structure which forces some of the state constraints (i.e., where we can't end up with with a wrong combination of properties), it will simplify our life in the future.

One potential way (and not sure it is a good one) to think about different states is to try to describe them as a Rust enum. This way, we'd have one enum variant per possible state.

[tomyrd]

Along with the changes discussed here we can improve the way we deal with query filters, we should have a way to combine them. This stems from this comment.

[bobbinth]

I think one potential way that we may want to query the notes is something like: "get all notes that may have been affected by a sync response". Once we get such notes form the store, we could apply state transitions to them as discussed in #487 and then save the ones that have changed back to the store.

This may be a bit tricky to do in a single query because we basically want to get something like:

• All input notes matching a list of nullifies.
• All input notes matching a list of note IDs.
• All input notes involved in a list of transactions.

Not sure if there is a good way to combine this into a single request to the store though.