Shorten adaptive_concurrency/concurrency_controller paths

[wrowe]

Description:
Windows include paths must net out to no more than 240 characters in our observations.

This specific extension directory path is both redundant and breaks test compilation
on the Windows architecture. The C++ namespace is similarly redundant.

The controller is always identified in the context of the adaptive_concurrency scope.

The class name might be potentially ambiguous, so this is left as ConcurrencyController, while the namespace is simplified to AdaptiveConcurrency.Controller, but that aspect is up for discussion.

Risk Level: low
Testing: local
Docs Changes: n/a
Release Notes: n/a

[wrowe]

Requesting additional review by @lizan per discussion of PR 10542

[wrowe]

bazel clang-tidy and go_control_plane_mirror both look unrelated to this patch... envoy-macos doesn't have a great track record. Leaving this PR as completed and considering the CI passing from our perspective.

[sunjayBhatia]

/retest

error in circle ci: ERROR: An error occurred during the fetch of repository 'org_golang_x_tools'

[repokitteh-read-only]

🔨 rebuilding ci/circleci: go_control_plane_mirror (failed build)

🐱

Caused by: a #10560 (comment) was created by @sunjayBhatia.

see: more, trace.

[tonya11en]

Patch looks fine to me, but why this is causing problems related to the 260 character path size limit in Windows? Those include paths are less than 100 characters, so I don't understand how shaving off another ~20 chars fixes this?

[sunjayBhatia]

@tonya11en its not the include path in the file, it’s the resulting bazel build tree that’s the issue and the file path that ends up in the cl.exe params file, e.g the include param for the gradient_controller.h file becomes: /Ibazel-out/x64_windows-opt/bin/source/extensions/filters/http/adaptive_concurrency/concurrency_controller/_virtual_includes/concurrency_controller_lib + (the rest of the path to the file) \_virtual_includes\concurrency_controller_lib\extensions\filters\http\adaptive_concurrency\concurrency_controller\gradient_controller.h (total length of this minus the /I is 285)

Shaving down the redundant concurrency_ part of the path reduces this length quite a bit

[wrowe]

Please note that this PR is blocking #10542 so accelerated review and merge (to simplify that PR) would be most appreciated.

[tonya11en]

There's no reason not to merge this, so I'll approve. However, I'm confused as to how other instances of long path names will be prevented from breaking the Windows build. Is this going to be enforced somehow?

I'd really like to see some documentation in the tree explaining the windows path name requirements. Otherwise, Windows build CI failures will be pretty vexing for people who are unaware of the limitation. I'd like to see it written before merging this change, but since you're blocked I'll defer to @mattklein123 as to whether this can be merged without an explanation in the docs.

[mattklein123]

I'd like to see it written before merging this change, but since you're blocked I'll defer to @mattklein123 as to whether this can be merged without an explanation in the docs.

I'm OK merging this but I agree that we will need to do better here in terms of blocking changes that cause this issue and/or making it more obvious in the future.

[sunjayBhatia]

I'm confused as to how other instances of long path names will be prevented from breaking the Windows build. Is this going to be enforced somehow

blocking changes that cause this issue and/or making it more obvious in the future

PRs/commits will fail Windows compilation once #10542 is merged and will likely fail with error messages from the compiler mentioning No such file or directory for headers or other files that are in fact present. Do you think it is enough to document that error and the likely cause in Windows-developer docs here (or in bazel?)? (We have a WIP branch for a PR we're going to make around Windows-developer environment setup, we could have another related to common errors?)

[tonya11en]

@sunjayBhatia I think that will be very confusing and that people will go down a few different rabbit holes before looking in the Windows developer docs. There should be some kind of verification in the Windows build steps to ensure that these path lengths aren't exceeding the Windows filesystem limitations and to provide a failure message indicating the exact problem.