Update the DA to become consistent with latest code structure

[Aayush-Abhyarthi]

As per the comments in the PR - #246 few code changes are required -

1. Remove duplicate validations from DA and root.(Refer 1st point here). Also refer here
2. Check do we require 2 provider blocks. (Refer)
3. Check if we can make use of prefix in dns_config_name. (Refer here)
4. Check why we need 2 provider blocks in the DA. (Refer here)

[imprateeksh]

Good to have a different issue created. It would be very helpful if you mention all the points to be addressed in form of checklist.

[Aayush-Abhyarthi]

Striking out 1st point.
Reference - terraform-ibm-modules/terraform-ibm-secrets-manager-private-cert-engine#367 (comment)

[shemau]

Item 2.
This was a legacy from long ago. There is a private key secret for LetsEncrypt that was stored in secrets manager in the Ops account. Two accounts required two provider definitions. This essentially required all module consumers to have a second provider block IF they were creating a CA configuration.

This is a legitimate use case in the module that we might still expect consumers to see. For any consumer using the feature the code is required in the module.

Item 3.
ca_config_name and dns_config_name are conceptually the same. One names a certificate authority configuration and the other names a directory name service configuration. It makes sense to treat them the same.

The code referenced in the link potentially has a bug. Not in the dns_config_name, but in the ca_config_name. Both these values could be null. In the event that they are null, then the value passed should be null. The current code would either fail, or more likely pass the value of prefix and break with an obscure error.
The main module has count logic predicated on the those values being null meaning do not create the resource.

Item 4.
Two providers are required in the DA because the main module uses two providers. So this is really a duplicate of item 2. If item 2 (the main module) is updated, then the DA should be updated as well. There should not be a migration issue for the DA, because the two providers in the DA are hard coded to the same key (aka the same account).