feat(backend): implement subscription management module with superadmin controls (#128)

[anshika1179]

Closes #128

Description

This PR introduces a highly cohesive and scalable backend Subscription Management Module for RestroHub. The architecture is designed to support the SuperAdmin role for managing standard restaurant plans (e.g., Free, Basic, Pro, Custom) and laying the groundwork for robust feature access controls (addressing future requirements like Issue #129).

Key Architectural Changes

• Isolated Module: All logic is intentionally isolated within the com.restroly.qrmenu.subscription package. This ensures clean separation of concerns and guarantees zero merge conflicts with existing authentication or user management flows.
• Entity Modeling:
  • SubscriptionPlan: Core model containing pricing, billing cycles, and active status.
  • SubscriptionFeature & PlanFeatureMapping: Dynamic feature toggle mapping structure to prevent hardcoded feature restrictions.
  • RestaurantSubscription: Links an active t_restaurant_master record to a specific SubscriptionPlan with defined start/end dates.
• Database Migrations: Entity relationships are mapped to ensure Hibernate ddl-auto=update generates the t_subscription_plan, t_subscription_feature, t_plan_feature_mapping, and t_restaurant_subscription tables seamlessly on launch.

API Capabilities

Exposes comprehensive REST APIs fully secured via Spring Security's @PreAuthorize:

• POST /api/v1/admin/subscriptions/plans (SuperAdmin only)
• PUT /api/v1/admin/subscriptions/plans/{id} (SuperAdmin only)
• GET /api/v1/admin/subscriptions/plans (SuperAdmin only)
• POST /api/v1/admin/subscriptions/restaurants/{restId}/assign (SuperAdmin only)
• GET /api/v1/restaurant/{restId}/subscription (Restaurant Owner & SuperAdmin)

Verification Checklist

• Code strictly adheres to the existing Java codebase style and architecture.
• Logic securely checks for appropriate JWT role context (SUPER_ADMIN vs RESTAURANT_OWNER).
• Tested endpoint logic to verify dynamic mapping of plans to restaurant entity relationships without mutating the original Restaurant core code.

Next Steps (Post-Merge)

• The base utility method isFeatureEnabled() has been added to the SubscriptionService which can now be utilized globally to restrict feature endpoints depending on a restaurant's active plan.

[anshika1179]

@rdodiya i had sent the pull request kindly check it once and if any modification required let me know

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.