feat(apisix-standalone): separate inline upstream

[bzp2010]

Description

ADC uses the upstream that is inlined in service, which means it needs to be written that way in adc.yaml.

services:
  - name: demo
    upstream:
      nodes:
        - host: 1.1.1.1
          port: 443
          weight: 100
    routes:
      - uris: [/*]

In the past, we did the same thing on each backend, but this caused some problems for APISIX. When the service resource was modified (because its internal upstream configuration was modified), it would cause the routing tree to be rebuilt.
According to APISIX's current routing tree reconstruction mechanism, this could cause sudden CPU spikes and result in additional traffic delays.
In Ingress Controller scenarios, changes to pod IP addresses are very common. It doesn't make sense for changes to pod IP addresses to further affect routing tree reconstruction and traffic proxying.

To avoid this issue, we have split the inline upstream in the backend implementation, replacing the upstream on the service with an upstream_id reference. This allows us to avoid the aforementioned issues.
No need to modify adc.yaml, everything is transparent and quietly completed in the background during sync and dump.

This PR implements this optimization in the apisix-standalone backend, and I also plan to implement it in apisix backend, which will be completed in another PR. API7 backend does not require this, as its control plane has already implemented the necessary functionality.

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

[oil-oil]

Suggested change

	newConfig[upstreamResourceKey] = [];
	newConfig[upstreamResourceKey].push({
	...this.fromADCUpstream(
	(event.newValue as ADCSDK.Service).upstream!,
	),
	id: event.resourceId,
	modifiedIndex: timestamp,
	name: event.resourceName,
	});
	newConfig[upstreamResourceKey] = [{
	...this.fromADCUpstream(
	(event.newValue as ADCSDK.Service).upstream!,
	),
	id: event.resourceId,
	modifiedIndex: timestamp,
	name: event.resourceName,
	}];

If there are no other considerations, this change is more concise.

[bzp2010]

The newConfig is derived from the old configuration as a deep clone, not an empty object. Therefore, the key is not necessarily empty, and it is not feasible to override it directly.

[oil-oil]

Suggested change

	if (!isNil(index) && index != -1) {
	if (index != -1) {

If findIndex is the only assignment method, then the value of index can only be a number.

[bzp2010]

The index is calculated by resources?.findIndex. Among ?, it is decided that if resources are undefined, this value may be undefined.

[oil-oil]

Suggested change

	if (!isNil(index) && index != -1) {
	if (!isNil(index) && index != -1) {

ditto

[juzhiyuan]

I reviewed the test cases and core changes and thought it would be nice to cover those cases:

1. A service does not include inline upstream.
2. An upstream referenced by multiple services.

But I think this can also be ensured by apisix itself?

LGTM

[bzp2010]

@juzhiyuan

1. A service does not include inline upstream.

This should be possible, for example, when using some serverless plugins.
However, ADC is now not adapted to this scenario, and the upstream in the service's schema is required. Unless the user uses --no-lint to bypass the check, the input will not be accepted at all.

2. An upstream referenced by multiple services.

ADC does not allow this use case, and the use of YAML anchor syntax will be inlined during parsing.

You may have some misunderstandings about the purpose of this PR. We have never allowed users to define upstream separately and reuse it with id, nor in this PR.

For ADC input, upstream must be inlined, which is no different from the original. This will be quietly completed behind the scenes and specific optimizations will be executed, and users should not have any perception of it.