Fix GlobalCredentials flattening function

[pnpdev10]

The flattenDiscoveryGetGlobalCredentialsItems function was attempting to set ALL possible credential fields for every credential type, causing "Invalid address to set" errors and JSON unmarshaling failures when creating and reading global credentials.

Problem

When executing terraform apply on the device-credentials example, users encountered errors like:

Error: Failure when setting GetGlobalCredentials search response
Invalid address to set: []string{"item", "0", "auth_password"}

Error: Failure when setting GetGlobalCredentials search response
json: cannot unmarshal bool into Go struct field ResponseDiscoveryGetGlobalCredentialsResponse.response.secure of type string

The root cause was that the flattening function tried to set SNMPv3-specific fields (like auth_password, privacy_type, snmp_mode) on CLI credentials, HTTP-specific fields on SNMP credentials, etc., causing type mismatches and invalid field assignments.

Solution

Modified flattenDiscoveryGetGlobalCredentialsItems in catalystcenter/data_source_global_credential.go to use defensive field setting:

• Always set common fields: id, comments, description, credential_type, instance_tenant_id, instance_uuid
• Only set credential-specific fields when they have meaningful values: Check for non-empty strings and non-nil pointers before setting optional fields
• Handle pointer fields safely: Check item.Port != nil && *item.Port != 0 before setting port values

Example

Before (CLI credential would incorrectly try to set SNMPv3 fields):

respItem["auth_password"] = item.AuthPassword  // Error: CLI doesn't have auth_password
respItem["snmp_mode"] = item.SNMPMode         // Error: CLI doesn't have snmp_mode  

After (only sets fields with meaningful values):

if item.AuthPassword != "" {
    respItem["auth_password"] = item.AuthPassword  // Only set if not empty
}

Result

• CLI credentials only get CLI-relevant fields (username, password, enable_password)
• SNMPv3 credentials only get SNMPv3-relevant fields (auth_password, privacy_type, etc.)
• HTTP credentials only get HTTP-relevant fields (username, password, port, secure)
• Empty/irrelevant fields are not set, preventing "Invalid address to set" errors

The fix is backward-compatible and defensive - it only improves behavior without breaking existing functionality.