Feat[MQB]: track queue depth per appId

[678098]

• Set queue stats to VirtualStorageCatalog on Primary and update per-appId queue metrics on these calls, if necessary
• Do sort json stats on admin command
• Add all the remaining queue metrics to json output
• Regenerate queue stats IT expected data

[678098]

sort is necessary to have less diff when we update sample json data in ITs
On the other hand, I can do this in ITs

[bmq-oss-ci]

Build 187 of commit 102331e has completed with FAILURE

[678098]

@dorjesinpo I checked your proposal to do this update in RootQueueEngine. The problem is that we don't expose message size (data->second.d_size) from this level (VirtualStorage/VirtualStorageCatalog) to the upper level of RootQueueEngine. Passing this up the exec stack will be harmful both for interfaces and performance.

[bmq-oss-ci]

Build 289 of commit 0ee07e5 has completed with FAILURE

[dorjesinpo]

We got rid of the loop in the put method and here it is back again.
At the moment, I do not see a good way to utilize VirtualStorageCatalog::numMessages so let's keep the loop.
Provided we won't maintain statistics for all Dynamic Apps.

[678098]

Check for empty d_subContextsHolder should be fast if we don't have subcontexts for dynamic apps.
We might utilize numMessages on the time when we do snapshot, but this change is more complex, since we don't have a good way to ensure that each and every virtual storage is alive, and this change is intrusive.
I would rather merge this PR for now, since it helps to test and compare queue metrics. We can think of this in the future, when we have prof outputs for the scenario in question.

[678098]

Actually, I would also like to move metrics update code to the header and mark it inline, with hope that it will have less impact on performance. We have inline functions defined for StatContext, but we break the inline chain here when we define in .cpp. I would also like to do this change after we merge metrics update.