GH-45961: [Release][Docs] Upload generated docs to GitHub Releases not apache.jfrog.io

[kou]

Rationale for this change

We want to stop using apache.jfrog.io. See also: #40760

What changes are included in this PR?

Upload generated docs to GitHub Release instead of apache.jfrog.io.

Our generated docs are only for publishing. We publish them to
https://arrow.apache.org/docs/ . So we don't need any migration path
for users.

Are these changes tested?

No. I want to try this in the next release.

Are there any user-facing changes?

No.

• GitHub Issue: [Release][Docs] Upload generated docs to GitHub Releases not apache.jfrog.io #45961

[github-actions]

⚠️ GitHub issue #45961 has been automatically assigned in GitHub to PR creator.

[kou]

Rebased. I'll merge in a few days if nobody objects this.

[assignUser]

-0
How many files will this end up being? Having the wheels and such be part of the github release makes sense, people are expecting that if they are not used to ASF ways. This on the other hand only uses the release area for temporary storage, littering it with files the users are not interested in.

I think artifacts would be a more appropriate storage for this and are easily manipulated using gh. Or should we create a workflow in arrow-site that uses the released binaries to build the docs?

[kou]

How many files will this end up being?

By this PR? Or by all related PRs such as #45962 and #45964?

This PR adds 3 files: docs.tar.gz{,.asc,.sha512}

All related PRs: 180:

3 [1 [source archive] * 3 [original + .asc + .sha512]] +
3 [1 [.mltbx] * 3 [original + .asc + .sha512]] +
126 [(1 [sdist] + 41 [wheels]) * 3 [original + .asc + .sha512])] +
45 [8 [(3 [for Linux] + 4 [for macOS] + 1 [for Windows]) * 3 [original + .asc + .sha512])] +
3 [1 [docs.tar.gz] * 3 [original + .asc + .sha512]]

FYI: #45470 adds more wheels.

Having the wheels and such be part of the github release makes sense, people are expecting that if they are not used to ASF ways.

The "people" refers Python users, right? In general, Python users use PyPI not GitHub Release.

I think artifacts would be a more appropriate storage for this and are easily manipulated using gh.

If we use GitHub Actions workflow artifacts, people who verify an RC need their GitHub token to download artifacts from GitHub Actions workflow artifacts.

BTW, we need to use multiple gh commands to download from GitHub Actions wokflow artifacts (gh workflow list and gh run download). We can use one gh release download command or just curl with GitHub Release.

Or should we create a workflow in arrow-site that uses the released binaries to build the docs?

It's an option but it's a bit risky. Building docs in a workflow in arrow-site may be failed after a vote...