Define additional repos only in submodules using them

[nineinchnick]

Description

By moving rarely used custom repositories to modules where they're actually used, this is supposed to avoid hitting them for every artifact.

Custom repositories are checked before central, defined in the Super POM, as described here: https://maven.apache.org/guides/mini/guide-multiple-repositories.html#repository-order

Is this change a fix, improvement, new feature, refactoring, or other?
Refactoring - doesn't change any functionality, might speed up jobs in the CI where the local repository is always empty.

Is this a change to the core query engine, a connector, client library, or the SPI interfaces? (be specific)
Only pom.xml.

How would you describe this change to a non-technical end user or system administrator?
n/a

Related issues, pull requests, and links

• Requested on Slack: https://trinodb.slack.com/archives/CP1MUNEUX/p1645440132007689

Documentation

(x) No documentation is needed.
( ) Sufficient documentation is included in this PR.
( ) Documentation PR is available with #prnumber.
( ) Documentation issue #issuenumber is filed, and can be handled later.

Release notes

(x) No release notes entries required.
( ) Release notes entries required with the following suggested text:

[hashhar]

Thanks, the duplication isn't bad enough to worry about IMO.
This should help builds with empty repos (CI/clean local runs).

Might want to add some context from the PR description to commit message too though.

[findepi]

submoules -> submodules

[nineinchnick]

trino-hive failure looks like a flake, it passed in the previous run and I only reworded the commit message now (without a rebase).
This failed:

2022-02-21T20:02:25.5986974Z 2022-02-21T14:02:24.485-0600	ERROR	pool-3-thread-2	io.trino.testng.services.ProgressLoggingListener	[TEST FAILURE] io.trino.plugin.hive.TestHive3OnDataLake.testInsertOverwritePartitionedAndBucketedExternalTable; (took: 25.5 seconds)
2022-02-21T20:02:25.6031582Z java.io.UncheckedIOException: java.net.SocketTimeoutException: Read timed out

But there's also a bunch of:

2022-02-21T20:02:25.7868983Z 2022-02-21T14:02:25.068-0600	INFO	Service Thread	io.airlift.stats.JmxGcMonitor	Major GC: application 103820ms, stopped 9909ms: 3.43GB -> 2.38GB

so maybe we could somehow tune the configs to fit the runners or there's a leak in tests. Should I investigate further?

[findepi]

so maybe we could somehow tune the configs to fit the runners or there's a leak in tests. Should I investigate further?

apache/maven-surefire#407 might be related.