add back METRIC_BYTES_FROM_STMGRS

[huijunwu]

Related to #1908

Since the change from TupleStreamMessage to TupleStreamMessage2, the tuple structure information was lost, thus the following count cannot be fetched.

• METRIC_BYTES_FROM_STMGRS
• METRIC_BYTES_FROM_INSTANCES
• METRIC_BYTES_TO_INSTANCES_LOST
• METRIC_BYTES_TO_INSTANCES

[srkukarni]

Shouldn';t this be CachedByteSize?

[huijunw]

I did not find the CachedByteSize() in protobuf.
There is SpaceUsed() which is noticeably slower than ByteSize()

[objmagic]

@huijunw https://developers.google.com/protocol-buffers/docs/reference/cpp/google.protobuf.message_lite#MessageLite.GetCachedSize.details

[huijunw]

thanks @objmagic

[objmagic]

@huijunw we should use ByteSize instead of GetCachedSize. In fact, before 557c980, we use ByteSize only.

[huijunwu]

@objmagic see the previous comment, GetCachedSize was suggested @srkukarni

[objmagic]

@srkukarni can you explain why we use GetCachedSize? I think its API description is not very clear. Will it return the correct current byte size of a message?

[srkukarni]

GetCachedSize returns the previously calculated GetByteSize. Thus in order for GetCachedSize to be valid, some one should have called GetByteSize and the message should not have been altered since then.
I am seeing that no one is calling GetBytesSize on HeronTupleSet. This means that GetCachedSize is likely incorrect.
Here is a proposal

1. In Stmgr-Server where stmgr first gets anything(either TupleStreamMessage from stmgr or HeronTupleSet from instance) we need to call GetByteSize().
2. Rest other places GetCachedSize should return the right values.
   Can we see whats the perf impact of these changes?

[objmagic]

@srkukarni makes sense. I was worried if we do not call ByteSize first we won't get correct value of GetCachedSize. Your proposal looks good. We need to carefully make sure ByteSize will be called at the very first. Then use GetCachedSize all the way until we release it.

For perf, we may need more time to fix the viz.

This proposal may help #2253 as well.