* [maven-release-plugin] prepare release v8.8.0

* [maven-release-plugin] prepare for next development iteration

* Create changes-8.8.0.md

* Reset changelog for 8.9.0

* [maven-release-plugin] prepare release v8.7.0

* [maven-release-plugin] prepare for next development iteration

* [maven-release-plugin] prepare release v8.4.0

* [maven-release-plugin] prepare for next development iteration

* [maven-release-plugin] prepare release v8.3.0

* [maven-release-plugin] prepare for next development iteration

* [maven-release-plugin] prepare release v8.2.0

* [maven-release-plugin] prepare for next development iteration

* [maven-release-plugin] prepare release v8.1.0

* [maven-release-plugin] prepare for next development iteration

* [maven-release-plugin] prepare release v8.0.0

* [maven-release-plugin] prepare for next development iteration

* Remove all shardingsphere cases.

Here are the basic and simple usages of the MeterSystem APIs.

## Meter Creation
New meter could be created based on metrics name, function, scope and data type. 
1. Metrics name is still the storage entity name.
2. Functions are every similar with the OAL function, just accepting different input.
```java
final MeterSystem meterSystem = MeterSystem.meterSystem(getManager());
meterSystem.create("test_long_metrics", "avg", ScopeType.SERVICE, Long.class);
```
NOTICE, this creation should only be called in the `module#prepare` stage, otherwise, `Can't create new metrics anymore` exception will be raised after the **CORE** module `start` stage finished. You may find out, there is a chance `create` could be executed successfully in your own `module#start` stage, but it it just because of the sequence of provider loaded by the class loader, **no guarantee, so please don't do that**.

## Runtime Calculation
`AcceptableValue` is the object created at the runtime to accept new metrics value.
```java
         final MeterSystem service = getManager().find(CoreModule.NAME).provider().getService(MeterSystem.class);
        Executors.newSingleThreadScheduledExecutor().scheduleAtFixedRate(new Runnable() {
            @Override
            public void run() {
                final AcceptableValue<Long> value = service.buildMetrics("test_long_metrics", Long.class);
                value.accept(MeterEntity.newService("abc"), 5L);
                value.setTimeBucket(TimeBucket.getMinuteTimeBucket(System.currentTimeMillis()));
                service.doStreamingCalculation(value);
            }
        }, 2, 2, TimeUnit.SECONDS);
```

## Meter Functions
Right now, only `avg` function has been implemented. I submit this PR as soon as possible to get your feedback. I will add more functions.

## Notice
1. Make slow trace query available in the sampled record. Logically, they are the same thing. The UI doesn't need to concern about the trace as a special case.
2. Endpoint dependency will be removed from the dashboard. Because no query available for it. We will provide a new page for that in 8.1
3. Comparison page will be removed due to dashboard is powerful enough to replace it.

Motivation:

According the feedback from the community, the e2e tests are hard for
them to understand and get them started, so this pull request aims to
rewrite the e2e tests with some improvements:

- debuggable locally, now you can run every individual case directly
inside the IDE, just like running a plain unit test.

- same functionalities of multiple counterparts share the same codes,
cases like different storages and cluster coordinators share the same
codes, easy to add more similar cases.

- the "end" now extends to the Doccker images, meaning that some bugs
like #4483 and #4471 can be more easily and early to be discovered.

- codes style and license headers are checked

Modifications:

- adopt jupeter (a.k.a junit 5), testcontainers as the new test
framework, all containers are orchestrated by docker-compose.yml,
well-known technology that developers should be familiar with.

- rewrite all test cases and verify them.

- reorganize the workflows in GitHub Actions.

Result:

- new e2e test should be easy to add.

- closes https://github.com/apache/skywalking/issues/4472

* provide influxdb as a new storage plugin
Co-authored-by: Nkezhenxu94 <kezhenxu94@163.com>
Co-authored-by: 吴晟 Wu Sheng <wu.sheng@foxmail.com>

* Add TTL E2E test

* Add to Jenkins stage and minor bugfix

* Upgrade e2e container version

* Polish and minor fix

* Polish

* Support Gateway without agent

* Add e2e cluster tests

e2e test setup. cc @hanahmily @peng-yongsheng @IanCao @zhaoyuguang @JaredTan95 

# e2e test case
One single standalone Spring service, accessing H2 database. This service has been installed the agent. 
OAP runs in single mode with H2 storage too.

The e2e test will verify the results through GraphQL query
1. Traces exist.
2. Service/Service Instance/Endpoint exist and have expected metrics.
3. Topology exists and match expected.

* [maven-release-plugin] prepare release v6.2.0

* [maven-release-plugin] prepare for next development iteration

* Move submodule plugin.

* Always auto-submodule

* [maven-release-plugin] prepare release v6.1.0

* [maven-release-plugin] prepare for next development iteration

* Change keys location.

* [maven-release-plugin] prepare release v6.0.0-GA

* [maven-release-plugin] prepare for next development iteration

* Lock oracle and resin plugins version.

* Move resin and oracle plugin to openskywalking

* Restore submodule active.

* Add another submodule active command.

* Remove the wrong test cases in release and fix some doc issues.

* [maven-release-plugin] prepare release v6.0.0-alpha

* [maven-release-plugin] prepare for next development iteration

* Fix some doc

* Receiver, aggregate, server finished.

* Cluster module implementation finished.

#1009

* [maven-release-plugin] prepare release apm-5.0.0-alpha

* [maven-release-plugin] prepare for next development iteration

Fix assmbly for mvn clean install -Papache-release and update version to SNAPSHOT for SNAPSHOT release.