Simplify deployment: unify dstack and meta-dstack workflows

Bắt đầu bằng cách đọc kms/dstack-app/deploy-simple.sh và deploy-to-vmm.sh, sau đó so sánh các đầu vào của chúng với các workflow hostcfg và dl của meta-dstack's build.sh. Công việc được xem là hoàn tất khi entry point triển khai, bố cục thư mục, việc thu nhận guest-image và các đường dẫn development và production được hợp nhất như mô tả, trong khi việc build OS image từ mã nguồn vẫn là tùy chọn.

Problem

Setting up dstack currently requires understanding two repositories with different workflows:

1. Two repos required for basic deployment

• meta-dstack: Config generation (build.sh hostcfg) and image download (build.sh dl)
• dstack: Components and deploy scripts (kms/dstack-app/deploy-*.sh)

New users must clone both repos and understand their relationship.

2. Inconsistent paths between dev and production

Same artifacts, different acquisition paths.

3. Deploy scripts in unexpected location

• kms/dstack-app/deploy-simple.sh and deploy-to-vmm.sh deploy to VMM
• These aren't KMS-specific—they're general CVM deployment scripts
• Expected location would be top-level deploy/ or similar

4. Guest image acquisition differs

• Dev: Requires meta-dstack checkout, then ../build.sh dl
• Prod: Direct download from https://github.com/Dstack-TEE/meta-dstack/releases

Both get the same tarball via different paths.

Impact

• Steeper learning curve for new operators
• Documentation must explain two different workflows
• Easy to get confused about which repo/script to use
• Friction when switching between dev and production setups

Suggested Direction

• Single entry point for deployment (no meta-dstack required for normal use)
• Unified deploy/ directory structure in dstack repo
• meta-dstack becomes optional (only needed for building OS image from source)
• Config templates with sensible defaults

This is a tracking issue for discussion. Implementation would be a larger effort.