Suggest to support retry strategy on verification step

[JohnNiang]

Description:

See https://www.rfc-editor.org/rfc/rfc9110#status.409 for more.

Below is an example of test case with retry strategy:

- name: recover
  request:
    api: /content.halo.run/v1alpha1/posts/{{(index .listPosts.items 0).post.metadata.name}}
    method: DELETE
  expect:
    statusCode: 200
  retry:
    on:
      statusCode: 409
    count: 10
    interval: 10s

[optional Relevant Links:]

• https://www.rfc-editor.org/rfc/rfc9110#status.409
• https://skywalking.apache.org/docs/skywalking-infra-e2e/latest/en/setup/configuration-file/#verify

[github-actions]

This issue has been open 30 days with no activity. This will be closed in 7 days.

[github-actions]

This issue has been automatically marked as stale because it hasn't had any recent activity.If you think this should still be open, or the problem still persists, just pop a reply in the comments and one of the maintainers will (try!) to follow up. Thank you for your interest and contribution to the api-testing.

[LinuxSuRen]

In a microservices architecture, users might need to wait until all the related services are ready. The following usage could achieve the desired outcome:

name: aiums
api: |
  {{default "http://localhost:18080" (env "SERVER")}}
items:
  - name: login
    before:
      items:
        - httpReady("http://gateway:17001/actuator/health", 2400, 'components.discoveryComposite.components.eureka.details.applications["AUTH"] == 1')
    request:
      api: /auth/login
      method: POST
      header:
        Content-Type: application/json
      body: |
        {
          "userName": "admin",
          "password": "admin"
        }

By the way, all the services should be stable once they are ready in my view,

cc @JohnNiang

[JohnNiang]

Hi @LinuxSuRen , thank you for reminding me!

I will try it later.