Expose generic error codes for CredentialsManagerError

[kailash-b]

Changes

Added

We now expose platform agnostic generic error codes that represent different exception scenarios common in both android and iOS.
We have considered only the CredentialsManagerError for now.
Keeping the backward compatibility in mind, a new field with the generic error code has been exposed via the BaseError class.

The users can leverage the field as below :

try {
  const credentials = await auth0.credentialsManager.getCredentials();
} catch (error) {
  if(error.generic_error_code == "NO_CREDENTIALS"){
    // handle scenario
  }
}

Note : The old behaviour still remains untouched.

References

• The changes partially address the ask in Platform-agnostic errors and types #923
• SDK-5643

Testing

• This change adds unit test coverage
• This change has been tested on the latest version of the platform/language or why not

Checklist

• I have read the Auth0 general contribution guidelines
• All existing and new tests complete without errors
• All active GitHub checks have passed

[poovamraj]

Let's use field name like

• identifier
• reason
• type

Or something that will be generic and can fit in a single word.

The purpose of the field will be extensively documented so it would be a one time learning that it is a platform agnostic error code.

[poovamraj]

What value do we provide to generic_error_code if for authentication errors.

[kailash-b]

It is left empty.
The field is currently populated only in case of a CredentialManagerException.
We can re-use this field when we collate the Authentication Errors as well (tracked as part of SDK-5700).

[poovamraj]

There is Enum.name field provided by Enums in Kotlin, can we use that to simplify the code? I haven't fired up my IDE to test this but looks like there is an opportunity to clean this one.

[kailash-b]

The Enums are internal in the underlying android SDK right now and we cannot access them.
We are leveraging the Public fields exposed via the Companion class.
However, we have a plan to migrate this .java code to .kt. Once that is done, we can leverage kotlin semantics and clean this snippet (tracked as part of SDK-5699)