Non-K8s name resolvers need to support namespacing

[ItalyPaleAle]

Spin-off from #3178 (comment)

Currently, all name resolvers except the K8s one do not support namespacing. This includes: consul, mDNS, and the upcoming SQLite (#3178).

Although those resolvers are primarily meant for local development, where namespacing is perhaps less used, it should still be implemented to support advanced scenarios and improve security.

Implementing namespacing is currently not possible unless the runtime participates too.

• Update nameresolution.Metadata to add a pre-defined constant for NAMESPACE (as a side note, we should probably use something with stronger typing than just a map of strings with pre-defined keys)
  • Implemented in Local file-based name resolver with SQLite #3178
• Update the runtime to pass the namespace when registering with a name resolver
• Update the mDNS component to register the app using namespaces
• Update the Consul component to register the app using namespaces
• Update the SQLite component to register the app using namespaces

Important: To preserve backwards-compat, with mDNS and Consul if the namespace is the default one ("default") we must register the app both with and without a namespace. Or older versions of Dapr won't be able to invoke this app. This behavior must be supported for at least N+2 releases.

[JoshVanL]

I think we should make this a high priority item. Ignoring namespaces in name resolution means that any app can spoof the App ID of any other in another namespace, meaning they can receive traffic on their behalf. Even with mTLS enabled in 1.12 Dapr clusters, daprd will continue to send traffic to fraudulent daprds because of the legacy mTLS servers & clients accepting generic cluster.local DNS identities.

Given the severity of this vulnerability, I think having backwards compat for N+1 is more appropriate imo.