SAVE_INIT_DATA should pass seed when recovering from sync words

[darkdh]

1. Create a new sync device:
   webview->{GET_INIT_DATA}->deviceA->{GOT_INIT_DATA: {seed: null}}->webview->{SAVE_INIT_DATA: {seed: seed_ABCD}}

2. Add a new sync device:

3. deviceA generate sync words from seed_ABCD

4. Paste sync words into device B for recovery
   webview->{GET_INIT_DATA}->deviceB->{GOT_INIT_DATA: {seed: seed_ABCD}}->webview->{SAVE_INIT_DATA: {seed: null}}

5. webview should NOT give us null seed

[diracdeltas]

the seed doesn't actually get sent to the server, btw (otherwise the server would be able to decrypt records). it is only sent between the sync client and the sync webview process.

[darkdh]

gotcha, I updated the issue description

[diracdeltas]

@darkdh the reason seed is empty in the 2nd case is because Device B already has the seed (it is sent to the sync webview in GOT_INIT_DATA: {seed: seed_ABCD}). According to the specification in client/constants/messages.js, browser must save values in persistent storage if non-empty. We were assuming that Device B saved the seed already, so there is no need to save it again.

does this cause problems?

[diracdeltas]

the impact of https://github.com/brave/sync/pull/222/files#diff-6ce8437e6c27185736d22013ce441e15R71 is that clients like browser-laptop would end up saving the seed twice

[darkdh]

yes, we have problem saving those value in brave-core after dynamic loading sync extension
brave/brave-core@0571802
we can't get seed from words from sync library because we still waiting for extension loaded and initialized. And once it is loaded and initialized we receive GET_INIT_DATA, we don't have way to get seed from words because the call to extension is async so we have no way to reply correct seed even we have sync words.
And we have to do workaround like this
brave/brave-core@6c83036
but this doesn't use js library to get seed.

So the solution from brave-core for this would be caching sync words and calling to our extension handler of sending GOT_INIT_DATA and do passphrase.toBytes32 in it.
That is why we rely on SAVE_INIT_DATA.

cc @AlexeyBarabash

[diracdeltas]

ok, i'm not 100% sure but i think that wouldn't cause a problem for any of the existing implementations