Proposal: allow break change for APISIX-base package

[Sn0rt]

Description

The current problem is that APISIX limits dependence on the APISIX-base version during the packaging process, which results in all historical versions being affected when the next APISIX-base version makes destructive updates.
Detailed description: The current version 3.5 APISIX specifies the APISIX-base version in the package. The minimum version is 1.21.4.1.7 and the maximum is 1.21.5. If the next apisix-base version is 1.21.4.1.8, it is a destructive update. The released apisix is affected. Because installing APISIX will look for the latest version within the version range.

# Determine the min version of openresty or apisix-base
if [ "$OPENRESTY" == "apisix-base" ]
then
     min_or_version="1.21.4.1.7"
     max_or_version="1.21.5"
elif [ "$OPENRESTY" == "apisix-base-latest" ]
then
fpm -f -s dir -t "$PACKAGE_TYPE" \
     --"$PACKAGE_TYPE"-dist "$dist" \
     -n "$artifact" \
     -a "$(uname -i)" \
     -v "$PACKAGE_VERSION" \
     --iteration "$ITERATION" \
     -d "$OPENRESTY >= $min_or_version" \ 1.x
     -d "$OPENRESTY < $max_or_version" \ 2.x

The current idea is to solve the problem by adjusting version dependencies. The current situation is that the version number of apisix-base is based on the Openresty version number + patch number. For example, apisix-base-1.21.4.1.8 means that this is based on Openresty 1.21.4.1 8 patches.

Solution overview: Change the package name to APISIX-runtime; add the own version of APISIX runtime. The version information of openresty is no longer included because the APISIX version is more radical than openresty; the nginx version information is not included to weaken nginx.

For example: APISIX-runtime.MAJOR.MINOR. PATCH, APISIX-runtime is the package name.

• MAJOR major version number: when you make incompatible API changes.
• MINOR minor version number: When you make a backward compatible functional addition.
• PATCH revision number: when you make a backwards compatibility issue fix.