Recipe Manager Class with CRUD, Search/Sort, Users, and Version Control (Progressive Levels)

Problem: Implement a Digital Recipe Manager (4 progressive levels) Implement a class RecipeManager (or equivalent) that supports progressively unlocked functionality. Efficiency is not required; any implementation that passes the unit tests is acceptable. Data model Each recipe contains: name: str, ingredients: list[str], steps: list[str] recipe_id format: "recipe" + id, where id is sequential starting from 1 (e.g., recipe1, recipe2, ...) Recipe names are globally unique (case-insensitive). ingredients_as_string / steps_as_string: join items using a comma , (preserve original order). Level 1: Basic CRUD (no user-specific data) 1) add_recipe(self, name: str, ingredients: list[str], steps: list[str]) -> str | None Add a new recipe and return its recipe_id. If a recipe with the same name already exists (case-insensitive), return None. 2) get_recipe(self, recipe_id: str) -> list[str] If it exists, return [name, ingredients_as_string, steps_as_string]. If it does not exist, return []. Ingredients must be returned in the same order as provided to add_recipe. 3) update_recipe(self, recipe_id: str, name: str, ingredients: list[str], steps: list[str]) -> bool Update the recipe identified by recipe_id. Return True on success. Return False if: the recipe does not exist; or the new name conflicts with another recipe name (case-insensitive). 4) delete_recipe(self, recipe_id: str) -> bool Return True if the recipe existed and was deleted; otherwise False. Level 2: Search and sort 5) search_recipes_by_ingredient(self, ingredient: str) -> list[str] Return all recipe_ids whose recipes contain the given ingredient (case-insensitive match). Sort by: number of ingredients ascending, then recipe_id ascending. 6) list_recipes(self, sort_by: str) -> list[str] Return all recipe_ids. sort_by options: "name": lexicographically ascending by name; tie-break by recipe_id ascending. "ingredient_count": ingredient count ascending; tie-break by recipe_id ascending. For invalid sort_by, default to sorting by name. Level 3: Users and edits 7) add_user(self, user_id: str) -> bool Add a new user. Return True if added; False if the user already exists. 8) edit_recipe(self, user_id: str, recipe_id: str, new_name: str, new_ingredients: list[str], new_steps: list[str]) -> bool Any user can edit any recipe. Enforce name uniqueness (case-insensitive). Return True only if the user exists, the recipe exists, and the name does not conflict. Otherwise return False. Level 4: Version control and rollback Version history rules A recipe created via add_recipe has no version history until its first edit/update. A version entry is created automatically when a recipe is modified via: update_recipe(...): last_edited_by = "system" edit_recipe(...): last_edited_by = user_id 9) version_recipe(self, recipe_id: str) -> list[str] Return the recipe’s version history sorted by version ascending. Each entry is formatted as: <version>:<name>:<ingredients_as_string>:<steps_as_string>:<last_edited_by> Return [] if the recipe does not exist or has never been edited/updated. 10) rollback_recipe(self, recipe_id: str, version: int) -> bool Roll the recipe back to the specified version’s name/ingredients/steps. On success, append a new version history entry with: last_edited_by = "rollback" appended to the end; original history remains immutable. Return True only if the recipe exists, the version exists, and the rollback name would not conflict (case-insensitive). Otherwise return False. Example Input add_recipe Pancakes [flour,milk,egg] [mix,fry] get_recipe recipe1 Output recipe1 [Pancakes,"flour,milk,egg","mix,fry"]