docs: Add quickstart documentation

[adam-christian-software]

Context

I wanted to ensure that onboarding was very simple for users to play around with Polaris through a quickstart that does everything for you.

To that end, this is a quick_start docker compose file that will allow a user to auto-create a catalog, principal, privileges, etc and uses a MinIO-based connection. The Docker Compose file does not use any other scripts within the repository, so the user-facing documentation can be a one-line bash script.

There are no tests related to this as it is a getting started file.

Checklist

• 🛡️ Don't disclose security issues! (contact [email protected])
• 🔗 Clearly explained why the changes are needed, or linked related issues: Fixes #
• 🧪 Added/updated tests with good coverage, or manually tested (and explained how)
• 💡 Added comments for complex logic
• 🧾 Updated CHANGELOG.md (if needed)
• 📚 Updated documentation in site/content/in-dev/unreleased (if needed)

Docs Pics

Console Output

[snazy]

Meh, forgot to mention:
This one is really great for people to try out Polaris without having to run a lot of manual steps!

[adutra]

This is really amazing, a complete no-brainer 😆

[adnanhemani]

This is super great for reintroducing Quickstart! Thank you so much for doing this :)

I'm personally not a big fan of using MinIO here, as it may give off an (incorrect) impression that we are preferring a vendor/product for usage with Polaris. Using the local file based approach avoids all of that. But I also see the discussion in the PR regarding this topic, so I don't want to block on that. The usefulness of this PR far outweighs any negatives here!

[adam-christian-software]

This is super great for reintroducing Quickstart! Thank you so much for doing this :)

I'm personally not a big fan of using MinIO here, as it may give off an (incorrect) impression that we are preferring a vendor/product for usage with Polaris. Using the local file based approach avoids all of that. But I also see the discussion in the PR regarding this topic, so I don't want to block on that. The usefulness of this PR far outweighs any negatives here!

Yeah, @adnanhemani , that's a good point and I agree. Let me list out some shared values that I think we have:

1. We want end users to easily spin up Polaris. The one-line change idea does that.
2. We want the quickstart to be aligned with what the common user scenarios are. Anecdotally, I have seen a lot of users on the Slack channel like these sort of S3-compatible sources.
3. We want to be open-source first. Supporting Apache projects should be first option.
4. Supporting or giving the impression that we are providing a closed-source vendor is NOT what we want.

I believe that there are two conflicting ideas here:

1. We do NOT want to expose file-based object stores. A file-based approach would expose this to users and, in my opinion, the file-based object stores are only for local development and integration testing. They feel more akin to a "developer thing" rather than a "end user thing." Given that our easy onboarding goal is targeting end users, I would hope that we would not want to expose file stores.
2. On the other hand, you are right that MinIO has done some recent actions which seems to be less than open-source first. That being said, I have not found another option which is open-source first. We thought about Apache Ozone (https://ozone.apache.org/), but we ruled that out as we did not want to build on the Hadoop ecosystem. If you have other ideas, I'd love to chat!

[dimas-b]

Polaris docs have a variety of options for storage: https://polaris.apache.org/in-dev/unreleased/getting-started/creating-a-catalog/

Getting Started should focus on simplicity, in which case MinIO appears to be the best fit. Given that MinIO (still) has public docker images, I believe it is fine to use it for getting-started guides.