Provide more options for starting dehydration

[uhoreg]

Needed for starting dehydration after restart -- since we only want to do that if we already have a key cached, and we don't need to try to rehydrate a device.

Fixes #4484

Checklist

• Tests written for new code (and old code if feasible).
• New or updated public/exported symbols have accurate TSDoc documentation.
• Linter and other CI checks pass.
• Sign-off given on the changes (see CONTRIBUTING.md).

[andybalaam]

I would prefer the above setup code to be in a function that takes arguments for the exact setup we need e.g. function setup(key_cached: boolean, device_exists: boolean, ...) ... and then separate tests for the things we want to be true:

it("should do nothing if no key is cached and onlyIfKeyCached is true")
it("should create a new key and device if no key or device exist")
it("should rehydrate an existing device using the existing key if it exists")
it("should create a new device if we don't have the key for the existing device")
it("should create a new device even if one exists if rehdrate is false")
it("should create a new device every time if createNewKey is true")

This would really help me understand what the code is supposed to do, and will help us understand what happened if future code changes affect this logic.

This is a preference, so if you have good reasons for this narrative style, you can ignore this request :-)

[uhoreg]

Changed.

The narrative style made sense when I was writing it, but this is probably clearer.

[BillCarsonFr]

How could I create a dehydrated device if I don't have the key cached? That would mean by creating a new key?
I am a bit confused by these options and how they work together. For example what happen if both createNewKey and onlyIfKeyCached are false?

Also why rehydrate optional?

I am not sure to understand how it links to the mentionned issue (#4484).
I mean if the app restarts and device dehydration is enabled it should schedule the next dehydration, and if it cannot because it doesn't have the key, the DehydratedDeviceManager should emit/notify that to the app (like we do -should do / sooon do- when another secret is missing? or whn backup isn't working).
Then the user fix it one way or another:

• getting the key => DehydratedDeviceManager is happy and schedule
• ~reset => DehydratedDeviceManager sees that there is now a key and is happy

What am I missing?

[uhoreg]

I added more to the comments to make it clearer. Do the options make sense now?

I am not sure to understand how it links to the mentionned issue (#4484).
I mean if the app restarts and device dehydration is enabled it should schedule the next dehydration, and if it cannot because it doesn't have the key, the DehydratedDeviceManager should emit/notify that to the app (like we do -should do / sooon do- when another secret is missing? or whn backup isn't working).

The idea is that if we already have the key cached, then when can go ahead and start dehydration immediately without bothering the user. If we don't have the key cached, we'll need to prompt the user (e.g. to unlock SSSS). 4484 is just for the simple case. The case(s) where we need to prompt the user would be covered by element-hq/element-web#29080 (and possibly others).