feat: return the production enclave information if present via GetEnclaves API

[Peeeekay]

This PR returns whether the enclave is running in production mode via GetEnclaves() api.

Sample Response for test enclave:
{
"enclaveUuid": "1a8396beea6a464d83ee27900eea012e",
"name": "vibrant-volcano",
"shortenedUuid": "1a8396beea6a",
"containersStatus": "EnclaveContainersStatus_RUNNING",
"apiContainerStatus": "EnclaveAPIContainerStatus_RUNNING",
...
}

Sample Response for prod enclave:
{
"enclaveUuid": "1a8396beea6a464d83ee27900eea012e",
"name": "vibrant-volcano",
"shortenedUuid": "1a8396beea6a",
"containersStatus": "EnclaveContainersStatus_RUNNING",
"apiContainerStatus": "EnclaveAPIContainerStatus_RUNNING",
"mode":"PRODUCTION"
}

[leoporoli]

LGTM, the only suggestion that I have is that it could be implemented by storing the enclave production mode value in the Docker labels and retrieving it by getting the APIC container's labels as we do for the other enclave information, like ports, enclaveID, etc. In order to normalize how the enclave info is stored and retrieved.
But it can be refactored later if this feat needs to be released soon.

[Peeeekay]

LGTM, the only suggestion that I have is that it could be implemented by storing the enclave production mode value in the Docker labels and retrieving it by getting the APIC container's labels as we do for the other enclave information, like ports, enclaveID, etc. In order to normalize how the enclave info is stored and retrieved. But it can be refactored later if this feat needs to be released soon.

Yes; make sense. I want to confirm with @victorcolombo about that as currently we store it as env variable and if it's ok to store it in label as well. I am not familiar if it cause some unintentional bugs.