CI: Set GMT_DATA_SERVER to the OpenTopography mirror in CI workflows

[seisman]

As inspired by conda-forge/gmt-feedstock#343 (comment), using direct URLs to the GMT data server is more stable.

This PR updates the CI workflows to use the mirror in China. It also reverts some workarounds for data download failures.

[seisman]

The Docs workflow still fails:

    Unexpected failing examples (1):
    
        ../examples/tutorials/advanced/draping_on_3d_surface.py failed leaving traceback:
    
        Traceback (most recent call last):
          File "/home/runner/work/pygmt/pygmt/examples/tutorials/advanced/draping_on_3d_surface.py", line 103, in <module>
            with rasterio.open(url_to_image) as dataset:
                 ~~~~~~~~~~~~~^^^^^^^^^^^^^^
          File "/home/runner/micromamba/envs/pygmt/lib/python3.14/site-packages/rasterio/env.py", line 464, in wrapper
            return f(*args, **kwds)
          File "/home/runner/micromamba/envs/pygmt/lib/python3.14/site-packages/rasterio/__init__.py", line 367, in open
            dataset = DatasetReader(path, driver=driver, sharing=sharing, thread_safe=thread_safe, **kwargs)
          File "rasterio/_base.pyx", line 329, in rasterio._base.DatasetBase.__init__
        rasterio.errors.RasterioIOError: CURL error: Failed to connect to oceania.generic-mapping-tools.org port 443 after 133284 ms: Could not connect to server

it seems it still use the default data server.

Actually, it's because this example explicitly uses the oceania URL. Now fixed f09b450

[seisman]

The China mirror seems to be too slow for CI, resulting in timeouts in the Cache Data workflow. This issue was resolved by switching to the OpenTopography mirror in 29c6eb7.