Update WebContentDecryptionModuleSessionImpl to the latest EME spec.

content/renderer/media/webcontentdecryptionmodulesession_impl.h

Index: content/renderer/media/webcontentdecryptionmodulesession_impl.h
diff --git a/content/renderer/media/webcontentdecryptionmodulesession_impl.h b/content/renderer/media/webcontentdecryptionmodulesession_impl.h
index 12c4fc31fa6306e1713ea10d65e6779a1359b0c5..760e13af50f93b02e68565dfe789bebadae5f689 100644
--- a/content/renderer/media/webcontentdecryptionmodulesession_impl.h
+++ b/content/renderer/media/webcontentdecryptionmodulesession_impl.h
@@ -34,10 +34,17 @@ class WebContentDecryptionModuleSessionImpl
 
   // blink::WebContentDecryptionModuleSession implementation.
   virtual blink::WebString sessionId() const;
+  virtual void initialize(const blink::WebString& mime_type,

[ddorwin, 2014/01/07 01:17:59]

I don't think "initialize" is a good long term name.

If a session object was created with loadSession(), initialize() wouldn't make
sense. In that scenario, GKR() is more accurate.

Also, the spec now says to "Process type and initData" because there is no
guarantee that a request will be generated.

I don't have any suggestions better than processInitData(). I had a hard time
with the spec language too.

[xhwang, 2014/01/07 01:38:25]

I like "initialize" because it's generic and can be interpreted as needed
(similar to "update"). I agree GKR is more accurate about what we do, but in
chromium implementation we also generate the session ID in this call. So GKR
doesn't cover all what we do.

Also, I feel "init"ialize("init"_data) matches pretty well. But this is not
important :)

For loadSession, the proposal is loadSession(DOMString sessionId), which doesn't
pass in a init data, so "initialize" or "GKR" won't be called in this class.

In summary, I like "initialize" better, but I am okay with GKR or other names if
you prefer :)

[ddorwin, 2014/01/07 02:41:37]

Maybe something like finishCreation but better. If you think about the scenario
where we have a load() method here, the session has already been "created" and
load is finishing the work of loadSession(). The two methods should be similar.

I think the problem becomes more apparent when you look at the Blink side where
we have initializeTimer. What does the timer do? Would we have two separate
timers? If so, how would they be identified?

[ddorwin, 2014/01/07 02:41:37]

The problem with "initialize" is that something should always be initialized but
it doesn't apply to loadSession().

If you think about the scenario where we have a load() method here, the session
has already been "created" and load is finishing the work of loadSession(). The
two methods should be similar.

Maybe something like finishNewSessionCreation() or initializeCreatedSession()
but better. 

I also think the problem becomes more apparent when you look at the Blink side
where we have initializeTimer. What does the timer do? Would we have two
separate timers? If so, how would they be identified?

+                          const uint8* init_data,
+                          size_t init_data_length);
+  virtual void update(const uint8* response, size_t response_length);
+  virtual void release();
+
+  // TODO(xhwang): Drop generateKeyRequest() and close() after blink side is
+  // updated.
   virtual void generateKeyRequest(const blink::WebString& mime_type,
                                   const uint8* init_data,
                                   size_t init_data_length);
-  virtual void update(const uint8* response, size_t response_length);
   virtual void close();
 
   // Callbacks.