feat: Hard delete database and table

[stuartcarnie]

• Closes Hard Delete Table Option #26156
• Closes Automatic Hard Delete Table function #26157
• Closes Add hard delete database #26262

Summary

This PR implements hard deletion functionality for databases and tables in InfluxDB 3 Core (OSS). Previously, only soft deletion was supported, which marked objects as deleted but did not remove the underlying data or schema objects. This feature enables the complete removal of .parquet snapshot files for the deleted tables. The schema will be completely removed after a configurable grace period.

Configuration

Environment Variable	Description	Default Value
INFLUXDB3_HARD_DELETE_DEFAULT_DURATION	The duration from when a database or table is soft-deleted until the data is scheduled to be hard deleted.	72h
INFLUXDB3_DELETE_GRACE_PERIOD	Grace period for hard deleted databases and tables before they are removed permanently from the catalog.	24h

Usage Examples

# Set hard delete to occur 30 days after soft deletion
export INFLUXDB3_HARD_DELETE_DEFAULT_DURATION=30d

# Set grace period to 48 hours before catalog removal
export INFLUXDB3_DELETE_GRACE_PERIOD=48h

Notes

• Both values accept human-readable durations (e.g., "1h", "7d", "30m")
• The hard delete duration determines when data files are removed from object storage
• The grace period provides additional time after hard deletion before the catalog entry is permanently removed

Architecture

This builds on the existing retention-policy enforcement processing, adding files for the deleted schema. These removed files are added to the next snapshot and removed from object storage.

The PersistedFiles structure implements the ObjectDeleter trait:

influxdb/influxdb3_write/src/deleter.rs

Lines 15 to 21 in b154c83

	/// Trait for clients to be notified when a database or table should be deleted.
	pub trait ObjectDeleter: std::fmt::Debug + Send + Sync {
	/// Deletes a database.
	fn delete_database(&self, db_id: DbId);
	/// Deletes a table.
	fn delete_table(&self, db_id: DbId, table_id: TableId);
	}

Which ensures it is notified when it should delete the database or table. This accounts for individual hard-delete time for each table.

As a result, file deletions only happen if the node is accepting writes and therefore regularly snapshotting, which is the same for retention policy enforcement. It is possible files aren't cleaned up with the current implementation if:

1. A table is deleted,
2. server isn't receiving writes,
3. grace period passes, so schema is deleted from the catalog
4. server is shut down

[praveen-influx]

Looks good - should --hard-delete-default-duration be added to serve-all.txt as well? I couldn't see that in enterprise too. It's not a blocker, if it should be added we could add it in separate PR.