Default Policy Initialization #71

Description

The service must ensure that the default policies defined in authz.policy are available in the backend datastore (MySQL). These policies should be loaded exactly once during service initialization. Re-running the initialization should not create duplicates or alter the datastore if the default policies are already present.

Problem

• Initialization dependency: The enforcer relies on default policies being present in the datastore to enforce rules immediately after startup.
• Duplicate risk: If initialization is run multiple times, current behavior inserts policies again, potentially creating duplicates.
• Consistency requirement: The database state should remain stable across runs; initializing twice should have no side effects.

Requirements

1. Load the default policies from authz.policy into the datastore during service initialization.
2. Ensure idempotency: re-running initialization when defaults already exist must result in no changes.
3. Confirm that after initialization, the service always has access to the required default policies for enforcement.

Acceptance Criteria

• On first initialization, all default policies from authz.policy are inserted into the datastore.
• On subsequent initializations, no duplicates are created and the datastore state remains unchanged.
• The service can immediately enforce policies using the default set after startup.

Notes

• This issue is separate from runtime lifecycle management of policies, but complements it by ensuring a consistent baseline.
• Duplicate handling here is preventive: initialization should be idempotent by design, not by relying on duplicate cleanup later.