core,schedule: use KiB as the canonical internal unit for region sizes

[liyishuai]

Enhancement Task

Background

#10656 switched PD's internal approximateSize from MiB to KiB to improve empty-region detection. During that work we discovered that size values throughout PD are plain int64 with no unit annotation. Fields like LeaderSize, RegionSize, approximateSizeKib carry their unit only in naming conventions, not in the type system.

This caused real bugs: step.go wrote KiB values into StoreInfluence.LeaderSize / RegionSize fields that the store-scoring functions treat as MiB. No compiler error — just silently wrong scheduling decisions.

Proposal

1. Introduce a named type type SizeKiB int64 in pkg/core/ (or pkg/units/).
2. Use SizeKiB for all internal region/store size fields: RegionInfo.approximateSizeKib, StoreInfluence.RegionSize, StoreInfluence.LeaderSize, StoreInfo.regionSize, StoreInfo.leaderSize, thresholds like EmptyRegionApproximateSize, SmallRegionThreshold, etc.
3. Drop the separate MiB-denominated fields (approximateSize, GetApproximateSize() returning MiB). KiB is the single source of truth internally.
4. Convert to MiB only at the API/JSON boundary for backward compatibility (approximate_size in API responses, Prometheus metrics). Plain int64 division at the edge, no SizeMiB type needed.

This makes any MiB/KiB confusion a compile-time error rather than a silent scheduling bug.

Related

• Original issue: scheduler: use KB-level approximate_size from region heartbeat to improve empty region detection #10656
• PR: scheduler: use KB-level region size granularity for improved empty region detection #10657, proto: add approximate_size_kb to RegionHeartbeatRequest pingcap/kvproto#1460

[liyishuai]

/type development