Download server for Velero client

* https://github.com/vmware-tanzu/velero/issues/6167

### Background

At present, these data are stored in the object store, so the client connect to the object store directly and download the data.
However, this has some drawbacks:

* This assumes the target storing the data is always an object store. In future, Velero may save the data elsewhere, i.e., NFS, or through Unified Repo, for which, the storage is transparent
* This assumes the target storing the data is always accessible from the client side using signed URL. This is not always true, especially in the on-premise environments
Therefore, we need to create a mechanism that get the data from the Velero server on behave of the client and deliver them to the client.

* ALSO SEE (Discussion w/ community and replicated ) - notes
* [Google Docs: Copy of Velero NFS support](https://docs.google.com/document/d/1ntiv93yMVTUJZHlO-7_UxMLZtYmKOvPh3MnEWT16mWM/edit)
*

### Use Cases
* General Velero use case
* Replicated local volume provider plugin (NFS/PVC as backup storage)

### Requirements
* Velero can generate it's own Download Requests URLs that Velero CLI client on user side can reach in a secure manner to support following features:
* `velero logs`
* `velero describe`
* [Download Target](https://github.com/vmware-tanzu/velero/blob/main/pkg/apis/velero/v1/download_request_types.go)
* use experimental flag, tech preview in first upstream release

Requirements from replicated
- Download Requests CR continue using downloadUrl in status CR

### Download API endpoints
* need to expose a port ( route / ingress )
* Need HTTPS
* WhiteBoard
https://photos.app.goo.gl/sCEno8YbxKg6toaD6

### Potential v2
* caching

### Installation additional steps to use TLS enabled Download Server
OpenShift Route TLS Secure route options
- Edge
- optional requires own cert
- Passthrough
- Re-encrypt

#### Ingress
- provide hostname
- provide TLS cert
- Can be automated using Certifihttps://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/#requesting-a-certificate
- Create Certificate Signing Requests
- Approve
-
- User have to trust root CA that signed TLS
- Ideally ingress operator TLS is already trusted, otherwise trust this CA, OR use --insecure-tls flag when downloading

#### Plan
0. See how cert-manager may help here: https://docs.openshift.com/container-platform/4.12/security/cert_manager_operator/index.html
1. cert-manager Operator for Red Hat OpenShift allows you to integrate with external certificate authorities and provides certificate *provisioning, renewal, and retirement.*
2. Use Route from OpenShift to point to your http velero object and implement client https connection
3. Use 1 with modification to create your own CA certificates to use this in ingress controller in k8s cluster
4. Implement velero go https protocol for storage service and replace ingress ssl with that solution. You need to mount SSL certs into certFile and keyFile.

// go https protocol for storage service, ideally pluggable with local-volume-provider

package main

import (
	"github.com/gofiber/fiber/v2"
	"log"
)

func main() {
	app := fiber.New()

	// Define SSL/TLS configuration
	sslConfig := fiber.Config{
		Prefork:       false, // Disable prefork for HTTPS
		DisableKeepalive: true, // Disable keep-alive connections for simplicity
	}


	// Start Fiber server with HTTP on port 80
	go func() {
		err := app.Listen(":80")
		if err != nil {
			log.Fatalf("Error starting Fiber server on port 80: %v", err)
		}
	}()
	// Load SSL/TLS certificates
	certFile := "path/to/your/mounted/cert.pem"
	keyFile := "path/to/your/mountedkey.pem"

	// Start Fiber server with HTTPS on port 443
	go func() {
		err := app.ListenTLS(":443", certFile, keyFile, sslConfig)
		if err != nil {
			log.Fatalf("Error starting Fiber server with TLS on port 443: %v", err)
		}
	}()

	select {}
}