Light client friendly events

[pepyakin]

This PR proposes a solution for light client friendly SRML events.

Each deposited event can specify zero or more topics. A topic is a fixed sized value (atm, is just a hash). When an event is deposited with some topic, the runtime adds the index of this event in the <Events<T>> list to a mapping that maps from topics to lists of indexes.

Light clients can "subscribe" to changes of specific storage values (see #628). The idea is that light clients would subscribe to changes of the storage values for a topic they are interested in. When the light client detects a change, it fetches the contents of the indexes list for the specific topic and with this the light client can query events' data by the indexes.

Marking this as draft, since I don't know if this is the way that we want to go, I didn't test this with light-client nor inspected the storage values and there are some questions left

[gavofyork]

Be good to get an opinion on this @svyatonik

[svyatonik]

The idea seems OK to me. I'll submit some issues soon to not-to-forget what needs to be changed with changes tries. We need (at least) to extend changes tries API (and network messages) to allow fetching changes for several keys (here: topics) at once.

[pepyakin]

I've checked the storage entries and add a test. This should be ready for review then.

[pepyakin]

There might be a problem with this approach, marking it inprogress until we figure it out.

[gavofyork]

what might the problem be?

[pepyakin]

Yes, there is indeed a problem, although not a significant one.

Consider the case when an event E was deposited with a topic A.

So at the end of the block N the field <EventTopics<T>> will be like:

A => vec![EventIndex(0)] // 0 is the index of `A` in `<Events<T>>`

then, let's suppose that the same event E with the same topic A was deposited at the block N+1. Therefore, <EventTopics<T>> will look the same at the end of the N+1 block:

A => vec![EventIndex(0)]

Because the value at the storage location of A doesn't change there will be no notification of change between for the N+1.

I am still not entirely sure, but it seems to be a problem. If the light-client doesn't follow each block, and say, it "subscribes" to changes at the block N+1 it won't get the update.

To circumvent this problem we could store Vec<(EventIndex, BlockNumber)> in EventTopics instead of just Vec<EventIndex>. Or maybe even something like Option<(BlockNumber, Vec<EventIndex>)>.

[pepyakin]

Ok, I put up a commit which fixes this. However, I went with Vec<(EventIndex, BlockNumber)> instead of Option<(BlockNumber, Vec<EventIndex>)>. The reason for that is ::append is not available for this type. See the commit for details:
5f9ca06

Apparently it starts asking for a hand-rolled structure tailored for this particular use-case.

[gavofyork]

ok, but please add a TODO and issue explaining that this is highly inefficient and needs to be altered to Option<(BlockNumber, Vec<EventIndex>)> once we can implement ::append for it. please also assign it 1.x milestone

[xlc]

This seems like a breaking change and requires JS SDK side change as well.
@jacogr I don't think it is easy to have a JS SDK that compatible with Substrate versions that with and without this change.