Add "429"-related retry controls to the Adobe Workfront Custom API module in Fusion

[#1]

Description -

The Adobe Workfront custom API module (or any other Workfront API module) is often used to query various API endpoints.  That module doesn't appear to have any built-in mechanisms for handling a retry when a 429 (API rate limit exceeded) occurs, though this is a fairly standard and common occurrence in high-volume systems.

The existing way to handle this in a reasonable fashion is to:

1. Make the API call with the custom API module
2. Set an error handler from the module
3. On the error handler path:
   1. Sleep for some amount of time
   2. Retry the API call with a second custom API module that's configured the same way as the first
   3. Set a success handler on that "Resumes"
   4. Set an error handler on that second module
   5. On that error handler path:
      1. Do the same as on the first, and continue nesting this for as many attempts as you want/need

This is super unwieldy and means that the module configuration is duplicated or triplicated, meaning future changes need to be done multiple times, which is risky due to human error being a normal thing.

Why is this feature important to you -

Given how common the use of the Adobe Workfront modules are and how common the 429 error is, it would make sense to have a mechanism built into the module to allow for retries and some kind of backoff sleep time to be just part of the module's advanced configuration.  It reduces the cost to build and maintain these Fusion scenarios.

How would you like the feature to work -

Have at least one numeric entry in the Advanced Config section of the Workfront modules for "Number of retries if too many API requests", default to "1" to allow for compatibility with existing scenarios.

Optionally have another numeric entry in the Advanced Config section that allows for setting the sleep time.  It would be most ideal if there were options for constant sleep, linear sleep (increasing by "constant" times the retry count), exponential sleep, and/or random sleep between some range of numbers.

If the module exceeds the retry count, execute the error handler path as currently supported.

Current Behaviour -

See the description above.  The following image also shows how a chain of 429 retries gets to be unwieldy after even just a few API calls.  Imagine having to propagate a series of changes -- this creates 2x the work, all for a simple "retry" handling.