Do not default to storing `InMemoryChannelKeys` keys on disk

[TheBlueMatt]

We can re-derive these on startup, so we should. Using KeysInterface's read method makes this easy, but we probably want to move the write method into KeysInterface as well (if practical) to make things symmetric.

[devrandom]

This is complicated by the fact that the channel_parameters field is late bound.

[TheBlueMatt]

Yea, I played with it a little bit and found that. It's further complicated by the fact that InMemoryChannelKeys' serialization is a public API and ideally we wouldn't break it by splitting the serialization logic half into KeysInterface's read method (otherwise you just break up the read code into parts). Not quite sure what the forward direction here is, but maybe it's just swapping around the deserialization stuff to do what we want and working on serialization later.

[TheBlueMatt]

Note that this is still an issue for now, but #1867 did the first step of ensuring we can read variants that don't store the keys. Now we just have to wait a few releases and then stop writing backwards-compatibility data.

[tnull]

Note that this is still an issue for now, but #1867 did the first step of ensuring we can read variants that don't store the keys. Now we just have to wait a few releases and then stop writing backwards-compatibility data.

This was done in 7a951b1.

Closing as completed.