Add a note about the case where all keys are released after load()

[xhwang-chromium]

Considering the following case. A persistent-license is stored. However, after a CDM, UA or hardware update, the license could not be loaded by the CDM anymore. For example, a certificate associated with the persistent license has been reset during the update.

In this case, upon load() of the session ID, the UA has a few options:

1. Clear the session data and declare that the session doesn't exist, i.e. resolve the promise with false. But the original session can never be released any more.
2. Perform a full migration so that the session is loaded as normal. However, the migration logic could be very complicated, and in many cases, simply impossible.
3. Load the session but declare all keys are released. The JS player can still call remove() on the session to trigger a license-release message, and finish the license release process. After the process, the JS player can recreate a session and store a new license if needed.

I think option 3 is the best in terms of user experience and complexity. It's much easier for the CDM to implement, and is easy to be handled by JS.

However, it's not mentioned in the current spec that without remove() having been called previously, it's possible that all keys are immediately released after load(). JS players may not handle this case correctly or at all.

In the current spec we have a note that sessions can be closed by itself:

The CDM may close a session at any point, such as when the session is no longer needed or when system resources are lost. In that case, the Monitor for CDM Changes algorithm detects the change and runs this algorithm.

I propose to add similar note in the spec under load() about this case.

[joeyparrish]

In this case, upon load() of the session ID, the UA has a few options:

1. Clear the session data and declare that the session doesn't exist, i.e. resolve the promise with false. But the original session can never be released any more.

This seems feasible, but not without drawbacks.

2. Perform a full migration so that the session is loaded as normal. However, the migration logic could be very complicated, and in many cases, simply impossible.

This seems infeasible to me, especially if there are private key changes involved. Let's not.

3. Load the session but declare all keys are released. The JS player can still call remove() on the session to trigger a license-release message, and finish the license release process. After the process, the JS player can recreate a session and store a new license if needed.

This seems fine to me if implementors feel that this is doable.