[yew1eb]

What changes were proposed in this pull request?

1. AbstractSource.addHistogram computes the label-aware key metricNameWithLabel but
   registers the Dropwizard histogram under the bare name, so every labeled variant of the
   same histogram shares a single reservoir. It now registers under metricNameWithLabel,
   consistent with addTimer, addCounter and addGauge.
2. AbstractSource.getAllMetricsNum now includes namedHistogram.size(), so the metrics
   capacity warning counts what getMetrics actually emits.

Why are the changes needed?

• With the old code, adding a label (e.g. a disk label on PartitionFileSize) makes all
  labeled variants read the same aggregated reservoir, so they report identical
  Count/Max/percentiles. It is latent today because the only two histograms
  (FetchChunkTransferSize, PartitionFileSize) carry no labels yet. Registering under the
  labeled key also keeps a future removeHistogram(name, labels) consistent with the other
  metric types, which remove by the labeled key.
• getMetrics emits histograms (fillInnerMetricsSnapshot(histograms(), ...)) but
  getAllMetricsNum ignores them, under-reporting the count used for the
  "number of metrics exceed the output metrics strings capacity" warning.

Does this PR resolve a correctness bug?

• Yes

Does this PR introduce any user-facing change?

• Yes

Labeled histograms report their own values instead of a shared aggregate, and the reported
total metric count grows by the number of histograms.

How was this patch tested?

Added test histogram with customized label to CelebornSourceSuite: it registers
PartitionFileSize with disk=disk1/disk=disk2, updates them with different values and
asserts each label reports its own _Max plus getAllMetricsNum == 2.

./build/mvn -pl common scalatest:test -DargLine= -Dsuites=org.apache.celeborn.common.metrics.source.CelebornSourceSuite

passes (7 tests); the new test fails when either fix is reverted.