Update to minio-0.20231214

Hey,

Here's a diff to update to minio-0.20231214. The reason I stopped
upgrading is because:

> The MinIO Gateway and the related filesystem mode entered a feature
> freeze in July 2020. In February 2022, MinIO announced the
> deprecation of the MinIO Gateway. Along with the deprecation
> announcement, MinIO also announced that the feature would be removed
> in six months time.
>
> As of
> https://github.com/minio/minio/releases/tag/RELEASE.2022-10-29T06-21-33Z,
> the MinIO Gateway and the related filesystem mode code have been
> removed. Deployments still using the standalone or filesystem MinIO
> modes that upgrade to MinIO Server
> https://github.com/minio/minio/releases/tag/RELEASE.2022-10-29T06-21-33Z
> or later receive an error when attempting to start MinIO.

From https://min.io/docs/minio/linux/operations/install-deploy-manage/migrate-fs-gateway.html

I struggled to identify whether my instance was impacted. Eventually, I
asked on their Slack channel. However, Minio people were not super
knowledgeable on the matter, but I got told I should be safe.
Unfortunately, minio wasn't building at that time on OpenBSD and it took
a month for my patch to trickle down to a release.

I tried to update then and... minio wouldn't start because I was
actually impacted by the deprecation.

I don't have the exact error message anymore, but it's from
cmd/format-erasure.go:
return "", fmt.Errorf(`found backend type %s, expected %s or %s - to migrate to a supported backend visit https://min.io/docs/minio/linux/operations/install-deploy-manage/migrate-fs-gateway.html`, meta.Format, formatBackendErasure, formatBackendErasureSingle)

I've no idea what the minio on OpenBSD users are running, and so whether
they will be impacted. So I guess the best move is to assume they are.

To migrate away from the deprecated mode, the procedure is documented:
https://min.io/docs/minio/linux/operations/install-deploy-manage/migrate-fs-gateway.html

So what should be done to help our lovely users go through, the best way
possible?

The upgrade must be done *before* upgrading. If a user already ran
`pkg_add -u`, it will be a pain to reinstall the old minio version
(libs bump and co)... unless we provide both version in the ports
tree. So, should we do this?

I thought about an entry in current.html (which will trickle down to
upgrade75.html) + a @ask-update in the PLIST. Is that right?

Last thing, previously the 'root' user/password was set in (one of) the
config file. With the new version, credentials must be set through
environment variables. (Otherwise it uses minioadmin:minioadmin.)
To that effect, I added
/usr/ports/net/minio/server$ cat pkg/minio.login
minio:\
:openfiles-cur=4096:\
:openfiles-max=8192:\
:setenv=MINIO_ROOT_USER=root,MINIO_ROOT_PASSWORD=yourstrongpassword:\
:tc=daemon:
(and got rid of the README).

But if I understand correctly pkg_create(1), the
`@sample ${SYSCONFDIR}/login.conf.d/minio` means it will be installed
verbatim, which is not acceptable. I guess the README should be
reinstated?

Lastly, please note that I only talked about the server component. I
didn't touch the client component (minioc/mc) yet, but the doc mentions
a "newest acceptable version" for the client as well, so similar care is
likely required.

Cheers,
Daniel