print replication levels in coordinator segment logs

[clintropolis]

Description

Improves coordinator load rule logging to include current replication levels, and adds missing segment id and tier information from some of the log messages. I've seen some strange behavior where segments become very over-replicated, particularly when multiple tiers are involved, but sometimes even when not, and am hoping these logging improvements can help track down the issue.

These logs should will print replication for all tiers, as well as consistently provide segment id and tier information:

2022-05-11T10:26:26,009 WARN [Coordinator-Exec--0] org.apache.druid.server.coordinator.rules.LoadRule - No available [_default_tier] servers or node capacity to assign segment [wikipedia_hour_2016-06-27T00:00:00.000Z_2016-06-27T01:00:00.000Z_2022-02-18T23:27:41.739Z]! Current replication: [[_default_tier:1/2]]

2022-05-11T10:31:26,123 INFO [Coordinator-Exec--0] org.apache.druid.server.coordinator.rules.LoadRule - Assigning 'replica' for segment [nested_test2_-146136543-09-08T08:23:32.096Z_146140482-04-24T15:36:27.903Z_2022-04-06T00:07:18.795Z] to server [localhost:8084] in tier [_default_tier]. Current replication: [[_default_tier:1/2]]

Also fixes a confusing log message about skipping drops which prior to this PR would always print if a segment was under-replicated on any tier, even if there was no tier to drop it from. Now this log message should only print when there is actually something to drop, as well as includes segmentId and from what tier the drop was skipped.

Finally, I've added currently served segment count to the EmitClusterStatsAndMetrics server details:

2022-05-11T10:26:06,056 INFO [Coordinator-Exec--0] org.apache.druid.server.coordinator.duty.EmitClusterStatsAndMetrics - Server[localhost:8083, historical, _default_tier] has 0 left to load, 0 left to drop, 28 served, 0 bytes queued, 370,550,415 bytes served.