Sign assets urls in first rows
When the API serves /first-rows, and if the CloudFront config has been passed through the environment variables, we now traverse the response content and sign every URL we find.

The response content contains unsigned URLs and comes from the database. We have to sign the URLs on the fly. Indeed, as they only last 1 hour, we cannot store them in the database.

<strike>
Note that:
> sign every URL we find
currently means:
> any string that starts with `https://datasets-server.huggingface.co/assets/`

This brings some false positives like:
1. an already signed URL
2. a string that is not a URL but starts with `https://datasets-server.huggingface.co/assets/`

Case 1. should not exist, but nothing prevents people from including case 2. in their data. As unsigned assets are easily forgeable, the only way would be to ensure it's from a feature like Image or Audio. But it means parsing more conscientiously. Do you think we should do it? (To me: it's good enough, and we can open an issue to work on it later if needed).
</strike>

-> we now only sign image and audio src we generate ourselves.

Follow-ups:
- setup the CloudFront config for the staging environment (in `/chart` and in infra's terraform configuration)
- setup the CloudFront config for the prod environment (in `/chart` and in infra's terraform configuration)

Sign assets urls in first rows: When the API serves /first-rows, and if the CloudFront config has been passed through the environment variables, we now traverse the response content and sign every URL we find.

The response content contains unsigned URLs and comes from the database. We have to sign the URLs on the fly. Indeed, as they only last 1 hour, we cannot store them in the database.

<strike>
Note that:
> sign every URL we find
currently means:
> any string that starts with `https://datasets-server.huggingface.co/assets/`

This brings some false positives like:
1. an already signed URL
2. a string that is not a URL but starts with `https://datasets-server.huggingface.co/assets/`

Case 1. should not exist, but nothing prevents people from including case 2. in their data. As unsigned assets are easily forgeable, the only way would be to ensure it's from a feature like Image or Audio. But it means parsing more conscientiously. Do you think we should do it? (To me: it's good enough, and we can open an issue to work on it later if needed).
</strike>

-> we now only sign image and audio src we generate ourselves.

Follow-ups:
- setup the CloudFront config for the staging environment (in `/chart` and in infra's terraform configuration)
- setup the CloudFront config for the prod environment (in `/chart` and in infra's terraform configuration)
