[FEATURE]: PayloadStorage functions should be public to support extending WorkflowClient/TaskClient

[lbestatlas]

Describe the Feature Request

In the deprecated conductor-client, the WorkflowClient was not declared as final, this made it possible to extend the Client to add additional ways to retrieve Entities and make other custom calls using the ClientBase methods.

The new WorkflowClient is declared final, so only public classes/methods are available. Custom calls are still possible using ConductorClientRequest.builder(), and ConductorClient. However, there is no publicly exposed way to populate or upload Task/Workflow payloads. Even the ExternalPayloadStorage class is also not publicly exposed.

Describe Preferred Solution

Make the following methods on the WorkflowClient public:

• populateWorkflowOutput
• checkAndUploadToExternalStorage

Make the following methods on the TaskClient public:

• populateTaskPayloads ( note: evaluateAndUploadLargePayload already public)

Pros

• simple change
• TaskClient already exposes evaluateAndUploadLargePayload for TaskRunner
• these methods do not change the internal state of the class so should be safe

Cons

• clutters the public interface with methods that may not be required for all consumers

Describe Alternatives

A clear and concise description of any alternative solutions or features you've considered.

Remove the final declaration from WorkflowClient and TaskClient and make the above mentioned methods protected Pros

• Same as preferred solution

Cons

• forces inheritance to extend rather than composition

Add new public classes WorkflowPayloadStorageClient and TaskPayloadStorageClient that contain the functionality of the methods above.

Pros

• Further modularises payload storage functions out of WorkflowClient/TaskClient

Cons

• more refactoring