Implement googContentType GetStats metric reported on receive side.

webrtc/call/video_receive_stream.h

Index: webrtc/call/video_receive_stream.h
diff --git a/webrtc/call/video_receive_stream.h b/webrtc/call/video_receive_stream.h
index 18e904d076489fdddf99b667d6f37dd90c163fb2..dae4fef2e02d95701baced54975b2e7f391a9852 100644
--- a/webrtc/call/video_receive_stream.h
+++ b/webrtc/call/video_receive_stream.h
@@ -87,6 +87,9 @@ class VideoReceiveStream {
     int width = 0;
     int height = 0;
 
+    // "screen" vs "realtime".

[tommi, 2017/08/30 15:03:27]

if these are fixed constants, can we use const char* instead of allocating
memory and make construction/destruction slightly more complex?  Alternatively,
can this be an enum?

[ilnik, 2017/08/30 15:30:24]

Enum is absolutely not suitable here, as we want it to be flexible. Also,
another enum for ContentType is annoying.

char* is problematic for the same reasons. What if we decide to put additional
information in here (like simulcast layers and experiment id).

[tommi, 2017/08/30 17:54:42]

Since stats gathering is a notoriously performance sensitive process, can you
clarify what you mean with 'annoying'? :)

Does it cause problems at the upper javascript layers?  In my mind, it would be
much less desirable to have to compare a string in chrome to some other
definition of "screen" vs "realtime" vs whatever else might be introduced. 
Further still, if one value gets removed or modified, it would be much better to
catch that as a build break rather than a string mismatch that silently makes it
into production.  And then there are cycles, locks and code bytes to consider :)

[ilnik, 2017/08/30 18:12:18]

If we introduce a second enum, it will be quite error prone to add new values to
all the relevant enums and there's a copy-paste. If we use a content type enum
from api/video_codecs it's a strange dependency we will need to put both in pc
and ortc. 

Finally, old GetStats is ultimately reporting all values as strings. This means,
that string conversion will still happen at the end. By using enums here we will
just delay that to the later moment. But now, at the cost of a single additional
string copy at each GetStats call (at most 10 calls per second in some
experiments. Default is 0.1 call per second) I get a code, arguably easier to
maintain. This is mainly because if i decide to change something about the
content type reporting value, all the changes will be contained in the
ReceiveStatisticsProxy, which my team is responsible for and it will be fast and
easy to make them.

[tommi, 2017/08/31 07:28:48]

Sorry for being slow but I'm still not fully underrstanding. Does "all the
relevant enums" mean individual values in the enumeration or other enum types?
Would it not be possible to have an enum type at the same place as "screen" and
"realtime" are today?

If it's a requirement that multiple values need to be encoded in the string,
then I'm wondering if this is the appropriate representation. Ideally these
values should eventually be standardized so we should not be adding/removing
'goog' stats without thinking those things through. This affects code and
databases in many places.
The old getStats API is being removed partially because of excessive string
copying and lack of strong types.

[ilnik, 2017/08/31 07:51:11]

Ok, I've made it enum everythere. Converting to string code now is in the
api/video_content_type.cc. I sure don't want to introduce another enum for
content type.

Again, main reason i wanted to leave it as a string was that all the logic was
in the place it could be easy modify later. Maybe it's too selfish. Of course,
quality of codebase is more important here.

+    std::string content_type;
+
     int sync_offset_ms = std::numeric_limits<int>::max();
 
     uint32_t ssrc = 0;