Another mechanism to achieve Forward Security, without changing the protocol

For the record, I have designed the VLESS and XTLS protocols, and I started the Xray-core project a month or so ago.
So those involved in the discussion should have basic level of knowledge of protocol design, engineering practices, etc.

Here's another idea after #177. It can solve existing problem without changing the protocol, but have one limitation. Note that none of my designs require the introduction of additional long-term channels or bring in identifiable features, which is the basic guideline.

1. On initial configuration, the server generates the random key, along with a corresponding timestamp.
2. newkey = hash(oldkey), with updated timestamp, regularly, e.g. hourly. The old key should not be retained.
3. This requires the same time on both sides. And it's not recommended for multiple clients to share key.

In addition, if the configuration is immediately imported to the user's client, actually the timestamp can be ignored during the import, thus eliminating the need to synchronize the time.

Read this proposal together with the referenced issue #177 and the VLESS and XTLS context linked in the description. No repository files, tests, entry point, or acceptance criteria are identified, so the intended implementation scope and definition of done need clarification before work can start.