Normalized hostname by concatenating scenarioName with index number

[zrlw]

By now, the default hostname of every dubbo-samples testing container is set to the service name, but

1. Many test projects define same service name in their case-configuration.yml, these test projects could not be ran simutaneously because two or more containers could not using same hostname at the same time,
2. it is difficult to ensure that manually setting service name do not overlap with other projects,
3. scenarioName might be unique because it's generated from project name which should be unique,
4. there are maximum length limit of hostname in container,
   so normalizing hostname by concatenating scenarioName with index number might alleviate this issue.

Setting hostname manually if some service system property or environment value contains hostname as it is difficult to determine whether part of a property or environment value is a hostname. In this situation, hostname should be set to global unique value explicitly at case-configuration.yml, and it should be different from serviceName to let this PR don't normalize it, just like this one:

services:
  provider:
    #set global unique hostname if some service system property or environment value contains but is not equal to the servicename: provider
    hostname: some-global-unique-name
    ...
  test:
    environment: 
      # the XXX value contains but is not equal to the hostname of provider.
      - XXX=jdbc:mysql://some-global-unique-name:3306/xxx
    systemProps:
      #the property value contains but is not equal to the hostname of provider.
      - some-property-name=some-global-unique-name:3306

@AlbumenJ PTAL

[zrlw]

for example, dubbo-samples-async-generated-future-springboot named test as it's consumer hostname,

but there are more than one test projects besides dubbo-samples-async-generated-future-springboot named their test container hostname as test, when github actions run them concurrently, the problem that test container could not be started might occur, just like this one
https://github.com/apache/dubbo/actions/runs/13666970507/job/38210252086

Failed tests: 1
[4/34] [dubbo-sample-async-generated-future-springboot:1/1] TEST FAILURE: Run tests timeout, version: -Ddubbo.version=3.2.17 -Dspring.version=5.3.24 -Djava.version=8, please check logs: /home/runner/work/dubbo/dubbo/2-advanced/dubbo-samples-async/dubbo-sample-async-generated-future-springboot/target/logs

[zrlw]

i think there is an alternative solution:
Throw invalid configuration exception if service name does not contains scenarioName at ConfigurationImpl, force developers revise servicename at case-configuration.yml :)

[AlbumenJ]

i think there is an alternative solution: Throw invalid configuration exception if service name does not contains scenarioName at ConfigurationImpl, force developers revise servicename at case-configuration.yml :)

I agree :)

[zrlw]

ok, too many changes might have a huge impact, let's endure it for a while, just modify the problematic case-configuration.yml separately when issues arise.