Inline routing-release submodules

[maxmoehl]

Proposed Change

Instead of maintaining many repositories, inline the submodules into the release to reduce the overhead of managing multiple repositories and making changes which affect all of them.

Acceptance criteria

Less (or no) submodules.

Related links

Batch 1:

• Inline multierror sub-module #454
• doc: deprecate repo multierror#8
• Archive multierror repository community#1080

Batch 2:

• Inline submodules part 2 #457
• doc: deprecate repo cf-routing-test-helpers#14
• doc: deprecate repo cf-tcp-router#35
• doc: deprecate repo routing-acceptance-tests#28
• doc: deprecate repo routing-api-cli#29
• archive inlined routing-release submodules community#1094

Batch 3 (to-do):

• https://github.com/cloudfoundry/gorouter
• https://github.com/cloudfoundry/route-registrar

Remaining:

• https://github.com/cloudfoundry/routing-api: also a submodules of diego-release
• https://github.com/cloudfoundry/routing-info: also a submodules of diego-release

Follow-ups:

• Should we inline all sub-modules, we should remove automation for it as well.

[peanball]

Please also add a task for updating the routing-release pipeline.
Submodules are bumped here, among other things: bump-dependencies-go-mod.

I don't think it will break, but maybe we can then get rid of some dead code.

[maxmoehl]

We briefly talked about this in the WG Forum:

• routing-api and routing-info are also submodules of diego-release so we won't be able to inline them.
• I will check and add a warning to gorouter and route-registrar that we will inline them soon and people should wait with opening PRs.
• Once the outstanding PRs (primarily prometheus protobuf changes) are merged I will inline them as well.

It should be possible to migrate feature branches. If I find the time I will try it out and document the process should anyone have a branch in a fork they want to migrate after the inlining.