Should model types always be in the ::Models sub-namespace or remain in the same parent namespace as the clients, depending on amount of clutter?

[ahsonkhan]

This is a C++ design guideline question, which might also impact codegen for appconfig (FYI @antkmsft)
There seems to be a bit of inconsistency in our service SDKs on this topics.

For example, attestation has models in a ::Models sub-namespace.
The same is true for most of our service SDKs including Storage (Blobs, Queues, etc.), Tables, and KeyVault Administration

azure-sdk-for-cpp/sdk/attestation/azure-security-attestation/inc/azure/attestation/attestation_client_models.hpp

Lines 27 to 34 in ac3321c

	namespace Azure { namespace Security { namespace Attestation { namespace Models {
	/**
	* @brief The AttestationType type represent a Trusted Execution Environment supported by
	* the attestation service.
	*
	*/
	class AttestationType final

But others, like the hand-written KeyVault (Keys, Secrets, Certificates) keep the models within the parent namespace:

azure-sdk-for-cpp/sdk/keyvault/azure-security-keyvault-certificates/inc/azure/keyvault/certificates/certificate_client_models.hpp

Lines 25 to 31 in ac3321c

	namespace Azure { namespace Security { namespace KeyVault { namespace Certificates {
	class CertificateClient;
	/**
	* @brief Contains identity and other basic properties of a Certificate.
	*
	*/
	struct CertificateProperties final

When we initially shipped Storage, we decided to move all models into a sub-namespace, to avoid cluttering the client namespace (but it has it as a MAY, based on the amount of types):
Azure/azure-sdk#2010
#959

Should we ignore the outliers, and always emit client models in a ::Models sub-namespace going forward, or keep it flexible?

Otherwise, if we want to stick with the flexibility of having a ::Models namespace in some cases depending on how cluttered the parent namespace can become, we need a configurable option within the C++ code generator to opt-into generating the sub-namespace.
And establish some "rule of thumb" guidance around when to use it.
For example, we probably don't need it for AppConfig, since there's only one client with ~20 operations and about twice as many model types, but that's reaching the boundary. .NET doesn't put them in a Models sub-namespace, but Java does put them in their own .models package.

cc @LarryOsterman, @RickWinter

[LarryOsterman]

FWIW, the .Net Guidelines say that Model types may be in the Models namespace to avoid cluttering the top level namespace.

IMHO, model types (which are distinct from Options types) should be in a Models namespace. Options types (and other similar types) belong in the client namespace associated with the Option type.

[ahsonkhan]

Conclusion from team discussion:

• We will always emit models in the Models sub-namespace, rather than using a "threshold" based decision.
• We will keep Options in the parent namespace (consistent with other languages, don't want C++ to be an outlier)
• It is okay for KeyVault administration to keep the models within the namespace even if other KeyVault packages didn't have it.

Emitter follow-up:

• Fix generation of models