crypto: Add curve_key and sender_data_type columns to inboundgroupsessions table/store

[andybalaam]

No description provided.

[richvdh]

Note to self: this will mean the application release can't be rolled back without breaking everyone's sessions: we need to make sure this is called out, loudly, in changelogs all the way up the stack.

[richvdh]

As an aside: I wonder if, for future changes, there is a way we can do this that doesn't actually break compatibility. The addition of an index doesn't mean that the new database won't work with the old application, but the indexeddb version mechanism doesn't know that.

What if we did something like this:

• Promise that any future schema versions between 12 and (say) 19 will be backwards-compatible with applications expecting version 12.
• Replace this line with:

      if old_version > 19 {
         return Err("db too new");
      }
      Ok(IdbDatabase::open(name)?.await?)

Then, if we make a schema change that is actually breaking, we bump the version to 20 (there is no reason that schema versions have to be sequential).

[andybalaam]

See #3812 for Rich's follow-up on this idea.

[richvdh]

It's not a strong opinion, but it's worth noting that this whole thing can equivalently be written:

Suggested change

	let mut params = IdbIndexParameters::new();
	params.unique(false);
	object_store.create_index_with_params(name, &IdbKeyPath::str_sequence(key_path), &params)
	object_store.create_index(name, key_path.into())

... at which point, I really question whether the helper function has any value.

(even if you want to make the nonunique bit explicit, that's not much longer, because it can be written: IdbIndexParameters::new().unique(false))