Support Dapr component resiliency

[mattgallagher92]

Dapr components support resiliency policies, which can be configured via Arm Template/Bicep. It's in preview but I think it'd be worth adding to Farmer.

I can probably contribute it in the next few weeks, but just putting this issue here in case someone wants to make any comments before I do.

[mattgallagher92]

I'm thinking that it makes sense to add custom operations to DaprComponentBuilder. One question is how granular we want to make the operations. The following structure shows all the possible configuration options.

  properties: {
    outboundPolicy: {
      timeoutPolicy: {
          responseTimeoutInSeconds: 15
      }
      httpRetryPolicy: {
          maxRetries: 5
          retryBackOff: {
            initialDelayInMilliseconds: 1000
            maxIntervalInMilliseconds: 10000
          }
      }
      circuitBreakerPolicy: {  
          intervalInSeconds: 15
          consecutiveErrors: 10
          timeoutInSeconds: 5     
      }  
    } 
    inboundPolicy: {
      timeoutPolicy: {
        responseTimeoutInSeconds: 15
      }
      httpRetryPolicy: {
        maxRetries: 5
        retryBackOff: {
          initialDelayInMilliseconds: 1000
          maxIntervalInMilliseconds: 10000
        }
      }
      circuitBreakerPolicy: {  
          intervalInSeconds: 15
          consecutiveErrors: 10
          timeoutInSeconds: 5     
      }  
    }
  }

We could have:

• One resiliency_policy op
• Separate inbound... and outbound... ops
• Separate inbound_timeout..., outbound_circuit_breaker etc. ops.

Given that it's valid to specify some but not all of the policies, I'm inclined towards 6 separate custom operations.

[mattgallagher92]

I've started implementation on the branch corresponding to this issue. Some notes:

• Although it doesn't reflect the JSON structure, I think that having six separate fields on the resiliency policy type is warranted. Grouping them into two sets of three adds needless overhead.
• I've got the custom operations accepting primitive types at the moment, because that's what my LLM wrote for me, but I think that having them accept the relevant record may be preferable.

[mattgallagher92]

I've refactored the custom operations to use records in 5586fd6. It's better because there was ambiguity when there were multiple parameters of the same type (int) for different things. However, we do lose the ability to make some values optional (now the caller has to explicitly set those values to None), and maybe for the case where the record only has one field, we're just adding needless complexity?