[2.x] Fixes support for S3-Compatible Storage like Herd minio

[pintend]

Currently if you use vapor.js for file uploads, during local development you need to use a live aws account. There is no way to use cloudflare r2, minio, etc. for local development.

I created a minio service in herd to use for local storage development and was having weird issues where i either couldn't upload with vapor.js or render a public url for already uploaded files which these two issues would basically be toggled depending on my env configuration

---

Reproduce: create a minio service in herd and copy the env

Create a bucket in the MinIO dashboard

AWS_BUCKET=herd-bucket
AWS_ACCESS_KEY_ID=herd
AWS_USE_PATH_STYLE_ENDPOINT=true
AWS_SECRET_ACCESS_KEY=secretkey
AWS_DEFAULT_REGION=us-east-1
AWS_URL=https://minio.herd.test/herd-bucket
AWS_ENDPOINT=https://minio.herd.test

Problem:

• With minio AWS_URL must include the bucket name (e.g., https://minio.herd.test/herd-bucket) to make public URLs work.
• However, when AWS_URL includes a path, that path is duplicated in the signed upload URL generated by Vapor

Examples:

AWS_BUCKET=herd-bucket
AWS_URL=https://minio.herd.test/herd-bucket
AWS_ENDPOINT=https://minio.herd.test

Yields:

https://minio.herd.test/herd-bucket/herd-bucket/herd-bucket/tmp/UUID?query

---

AWS_BUCKET=herd-bucket
AWS_URL=https://minio.herd.test/laravel
AWS_ENDPOINT=https://minio.herd.test

Yields:

https://minio.herd.test/laravel/laravel/herd-bucket/tmp/UUID?query

---

AWS_BUCKET=herd-bucket
#AWS_URL=https://minio.herd.test/laravel
AWS_ENDPOINT=https://minio.herd.test

Yields:

https://s3.amazonaws.com/herd-bucket/tmp/UUID?query

ignoring the AWS_ENDPOINT

---

Fix:

The issue originates from how the S3 client is constructed in Vapor Core. It does not fully respect the configured disk settings and misuses AWS_URL as both the url and SDK endpoint.

I've updated the controller to use AWS_ENDPOINT if it exists which seems to make vapor core work with herd minio now.

[pintend]

Is there a specific reason why vapor users are "forced" into using s3 specifically? If an app requires multiple disks which may be on different accounts or regions the current implementation doesn't support that. Additionally if an app wants to use a 3rd party object storage like Cloudflare R2 (which has "free" egress) that wont either work.

Why dont we use the s3 client from Storage? e.g. Storage::disk('s3')->getClient() Wouldn't that be created by the same ENV keys anyway? then we don't even need the checks for AWS_LAMBDA_FUNCTION_VERSION