Implement download Transformer and Provider config files

Task: Upgrade Transformer and Provider Config File Endpoints to Support Downloading

Description:

This task involves upgrading the existing endpoints for generating configuration files for the Transformer GCZ and Provider GCZ services. Currently, these methods only store the files on the backend filesystem and return a status message. The task requires adding the ability to download the files via a download query parameter. Additionally, a spec discrepancy in the GET generateKoopConfig method has been identified, and a new POST method will be introduced to handle cases where a request body is required.

Requirements:

1. Transformer GCZ Config File (generateAppYaml):

   • Current Behavior: The method generates a YAML file for the Transformer GCZ service and stores it on the backend filesystem.
   • New Feature: Add support for downloading the YAML file through the download=true query parameter. If download=false (default), the file will continue to be stored on the backend filesystem, and the method will return a status message.

2. Provider GCZ Config File (generateKoopConfig):

   • Current Behavior: The method generates a JSON file for the Provider GCZ service and stores it on the backend filesystem.
   • New Feature: Add support for downloading the JSON file through the download=true query parameter. If download=false (default), the file will continue to be stored on the backend filesystem, and the method will return a status message.

3. Spec Discrepancy in generateKoopConfig:

   • Issue: A spec discrepancy has been identified where the GET method is optionally accepting a request body, which is against REST standards.
   • Solution: Introduce a new POST method to handle cases where a request body is needed for generating the Koop configuration. The GET method should no longer support a request body.
   • Reasoning
     • RFC 7231, section 4.3.1, specifies that GET requests should not have a request body:
       "A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request."
     • also, the Swagger UI renders it incorrectly (it marks it "required" and blocks normal method "Try")

4. File Handling:

   • Ensure proper handling of file existence and error responses if the file is not generated.
   • Store the files on the backend filesystem when download=false.
   • Ensure proper cleanup of temporary files (if applicable).

5. Swagger Documentation:

   • Update Swagger UI to reflect the new download query parameter for both endpoints.
   • Document the default behavior (download=false) and the behavior when download=true.
   • Ensure that the new POST method for the generateKoopConfig endpoint is properly documented.

Acceptance Criteria:

• The Transformer GCZ config file can be downloaded via the /admin/generateAppYaml endpoint when download=true.
• The Provider GCZ config file can be downloaded via the /admin/generateKoopConfig endpoint when download=true.
• If download=false (default), the files will be stored on the backend filesystem, and a status JSON will be returned.
• The spec discrepancy in the GET generateKoopConfig method has been addressed by introducing a new POST method for handling request bodies.
• Clear error messages are returned if the file is not found or cannot be generated.
• Both endpoints are documented and displayed in Swagger UI, including examples for the download query parameter and the new POST method.
• The implementation is covered by unit tests.