Better naming for components

[kvinwang]

This PR implements the Dstack part of issue Phala-Network/phala-cloud#25

Terminology Mapping

Current Name	Renamed To	Description	Implemented
Guest agent backend	-	-	-
tappd	dstack-guest-agent	The guest daemon running in CVM to provide services to the TEE app	✅
/var/run/tappd.sock	/var/run/dstack.sock	The unix socket file exposing dstack daemon services	✅
URL http://localhost/prpc/Tappd.<Method>	http://localhost/<Method>	The URL used to access the agent	✅
DeriveK256Key(...)	GetKey(...)	Get a ECDSA (K256 curve) priviate key associated with a signature chain	✅
DeriveKey(...)	GetTlsKey(...)	Get a ECDSA (P256 curve) priviate key associated with a x509 certificate chain issued by the key provider	✅
TdxQuote(...)	-	Removed, Get TDX quote with predefined hash schema of report_data	✅
RawQuote(...)	GetQuote(report_data)	Get TDX quote	✅
client sdk	-	-	-
*	*	Changes align to the backend	[ ]
TappdClient	DstackClient	API client name	[ ]
Other components	-	-	-
tproxy	dstack-gateway	The ingress server with automatic attested HTTPS	✅
teepod	dstack-vmm	The orchestrator to manage the lifecycle of CVMs on the host side	✅
kms	dstack-kms	The key privision service	✅

Note

The previous tappd API is still available at /var/run/tappd.sock. The renamed APIs serves on /var/run/dstack.sock.

[h4x3rotab]

Why does deriveKey(...) become getTlsKey and getP256Key? It's just key materials for any type of keys IMO?

The previous tappd API is still available at /var/run/tappd.sock. The renamed APIs serves on /var/run/dstack.sock.

Another approach would be to symlink stack.sock to tappd.sock, and serve the same API with backward compatibility. Which one do you think is better?

[kvinwang]

Why does deriveKey(...) become getTlsKey and getP256Key? It's just key materials for any type of keys IMO?

It isn't just key materials. The two types of key get different pubkeys and the pubkey is included in the cert chain or signature chain which proves the key's origin and owner(app-id).
Under the hood, getEthKey generates the keys locally while getTlsKey fetches the certificate from KMS each time, as KMS cannot issue an intermediate CA certificate for the application due to security constraints.

Another approach would be to symlink stack.sock to tappd.sock, and serve the same API with backward compatibility. Which one do you think is better?

Since all of the APIs have changed, I think a hard separation might be better as it forces the new apps to use the new APIs so that we can drop the old API support earlier. What's your preference?