[V3] Rename ErrorType exception properties to avoid hiding inherited member

[muhammad-othman]

Description

This change resolves a naming conflict in exception classes where the ErrorType property could hide the inherited ErrorType member from the base AmazonServiceException class.
Also removed previous customization approach at AccountService in favor of the generator-level fix, which caused the private property name to change but the pubic properties stayed that same.

Motivation and Context

DOTNET-8305

Testing

• Ran the generator and validated that only the AccountService was affect by this change.
• DRY_RUN-545fa4f9-fa52-429e-8579-fb9b15978715

Screenshots (if appropriate)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My code follows the code style of this project
• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have read the README document
• I have added tests to cover my changes
• All new and existing tests passed

License

• I confirm that this pull request can be released under the Apache 2 license

[peterrsongg]

I feel like this method name is a bit misleading. It suggests that we can override any property name but in reality it only overrides exception names and only if it is "ErrorType". Can we rename this to GetExceptionNameOverride or something along that line?

[muhammad-othman]

This intentional incase in the future was wanted to override other properties names for any reason, otherwise I would have added this if condition to the BasePropertyName.
Currently we are adding 3 lines in BasePropertyName to call two line in GetPropertyNameOverride, if we are sure we will never override any property for any reason then I think this method should be removed.

[peterrsongg]

Well, usually we would override a property name by making an entry in the Customization.json file and then using PropertyModifier or ShapeModifier. I would think that hardcoding an override based on the existence of a string is a pretty niche use-case

[peterrsongg]

For example: https://github.com/aws/aws-sdk-net/blob/main/generator/ServiceClientGeneratorLib/Member.cs#L231

We have a method GetPropertyModifier that allows us to override the name of a property. For any other override, we would usually make an entry and then call this method.

I get why you didn't use that b/c we don't want to have to do that every time a property of ErrorType shows up, but i think in most cases we would use the method available GetPropertyModifier

[muhammad-othman]

I didn't use this one for two reasons:

1. It it under customizations, so updating it will make it seem like this is a customization rather than a manual override.
2. It does much more than overriding the name, it accepts shape name and property name so wont know inside the shape type (though we can add an extra parameter with default value so this isn't a major concern), and it also returns a PropertyModifier which is a very rich object not just a name modification.

[peterrsongg]

okay, since it's a private method I'm not too adamant about changing the name.

[peterrsongg]

just to be clear i wasn't suggesting you use the customization, just that there is another method with a very similar name in that class

[muhammad-othman]

Now I see that you weren't suggesting that after rereading your comment :D, I'm open to removing it though so let's see what the second reviewer thinks.