mount: report data sizes to df with -df.logical (#10459)

df on a mount shows the space the cluster gives up to the data: every
replica of a regular volume, every shard of an ec one. That is the honest
answer for capacity planning, but it is not the question a user asks when
they want to know how much of their data is stored.

Add -df.logical. The master reports the logical sizes alongside the raw
ones: one replica per regular volume, the data shards of each ec volume
counted once. Free space is divided by the copies the requested
replication makes, so used plus available stays the amount of data the
mount can still write, and it comes off the cluster-wide usage rather
than one collection's, since capacity is cluster-wide too.

Statistics through a filer resolves an unset replication to the filer's
default rather than the master's, matching where the writes it is sizing
for actually land.

The flag governs the quota check too, so a mount has one notion of how
much it is using. A filer that predates the new fields sends zeros, and
the mount keeps reporting the raw sizes.

weed/storage/erasure_coding/ec_volume_info.go

@@ -18,6 +18,15 @@ type EcVolumeInfo struct {
 	EncodeTsNs  int64  // encode-run identity (unix nanos); one value per (volume, disk)
 }
 
+// DataShardsOrDefault returns how many of this volume's shards hold data; shard
+// ids below it are data, the rest are parity. Open-source SeaweedFS always uses
+// the fixed 10+4 layout, so this returns DataShardsCount. It is a per-volume
+// accessor, like EcShardsVolumeDataShards, so callers stay correct on builds
+// that derive the ratio per volume.
+func (ecInfo *EcVolumeInfo) DataShardsOrDefault() int {
+	return DataShardsCount
+}
+
 func (ecInfo *EcVolumeInfo) Minus(other *EcVolumeInfo) *EcVolumeInfo {
 	return &EcVolumeInfo{
 		VolumeId:    ecInfo.VolumeId,