Add `BadgerDBUpdate` method for `ResourceDefinitionModel`

[jim-junior]

Description

Extend the ResourceDefinitionModel struct by implementing a new standalone method called BadgerDBUpdate. To ensure backward compatibility across other application modules, do not modify or replace the existing etcd-based Update implementation. This method introduces native support for modifying an existing resource definition payload directly inside BadgerDB.

Requirements

• File Location: internal/models/resource_definitions.go
• Method Signature Strategy: Introduce a new method named BadgerDBUpdate(name string, definition []byte) error on the ResourceDefinitionModel struct.
• Transactionality: Execute both the prerequisite existence check and the database item updates within a single BadgerDB Update (write) transaction to uphold execution safety.
• Existence Verification & Error Handling: * Prior to saving the new bytes, check if the calculated lookup key exists in the database.
  • If the key does not exist, immediately return a descriptive custom "not found" validation error matching the error context returned by the legacy etcd function (e.g., fmt.Errorf("resource definition with name %s not found", name)).
• Key Generation: Generate the targeted key using the existing key(name) helper (i.e., /resource_definitions/{name}).
• Persistence: Overwrite or set the updated raw byte configuration data on the existing key path safely inside the write transaction scope.
• Testing: Add a dedicated unit test suite inside internal/models/resource_definitions_test.go to validate successful data modification paths and key-missing constraint paths.

Success Criteria

• The BadgerDBUpdate method is successfully added to the data layer model alongside legacy paths without modifying existing API signatures.
• The presence check and update operation execute atomically inside a single write-safe Update block.
• Invoking the update sequence on a missing item name correctly surfaces the custom validation "not found" error.
• Test Case implementation: A comprehensive unit test is provided that:
  • Seeds an isolated, in-memory BadgerDB instance with an initial test resource configuration payload.
  • Successfully overrides the existing payload by executing BadgerDBUpdate with a newly formatted byte slice.
  • Confirms via a fresh database transaction read that the value stored on that key reflects the new modifications perfectly.
  • Verifies that calling the update logic with a completely invalid configuration name safely drops out with the expected non-existent error message.