feat: improve API-driven standalone update reliability

[bzp2010]

Description

This PR aims to improve the reliability of configuration updates in API-driven standalone mode by implementing the following measures:

• A new "standalone-status" reporting mechanism has been added. Now, each subsystem on every worker will report the digest of its loaded configuration, down to the level of each entity type (worker:<id>:<subsystem>:<entity_type> = <digest>). This information will indicate whether the new configuration has taken effect on each worker (e.g., the router tree will be reset; the consumer lrucache will be flushed), and so on.

  • Technically, a worker reporting a digest simply indicates that the configuration has been loaded but does not necessarily reflect that the router has actually been rebuilt. The router is passively rebuilt based on differences in the conf_version value for each request; therefore, as long as conf_version has been updated, we can assume that the router has been rebuilt.

• The PUT /apisix/admin/configs request now supports a wait parameter. It allows you to specify a value in milliseconds; APISIX will collect if configuration applied status during this wait period and report it to the client. It is based on the report on "standalone-status" mentioned above.

  • This API now returns a 200 or 202. A 200 status code indicates that the configuration has been accepted and loaded on each worker, while a 202 status code indicates that the configuration has been accepted but its loading status is not guaranteed.
  • Configuration loading is expected to complete within 1 second, as each worker has a timer-driven loading mechanism. However, this may take longer under certain special circumstances (such as extreme CPU load).

• Refactor the configuration loading from shdict to improve the configuration loading latency window for new workers (which may be restarted via reload). Configuration is now always loaded synchronously during init_worker and consumed immediately during core.config.new.

All of the above changes are backward-compatible, and existing clients can work with them. Older clients do not send the wait parameter, so they will not trigger the new waiting behavior. The other changes are internal refactoring improvements that do not break compatibility.

Checklist

• I have explained the need for this PR and the problem it solves
• I have explained the changes or the new features added to this PR
• I have added tests corresponding to this change
• I have updated the documentation to reflect this change
• I have verified that this change is backward compatible (If not, please discuss on the APISIX mailing list first)