http: remove deprecated http_parser http1 codec

[ggreenway]

Fixes #33622

Risk Level: Low

[repokitteh-read-only]

CC @envoyproxy/runtime-guard-changes: FYI only for changes made to (source/common/runtime/runtime_features.cc).
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to (api/envoy/|docs/root/api-docs/).
envoyproxy/api-shepherds assignee is @abeyad
CC @envoyproxy/api-watchers: FYI only for changes made to (api/envoy/|docs/root/api-docs/).

🐱

Caused by: #38950 was opened by ggreenway.

see: more, trace.

[jmarantz]

I think we still have some uses of it internally that we are trying to track down.

[paul-r-gall]

Actively working on removing internal reliances. @ggreenway I've been on pat leave for several months which is why this is behind schedule.

[abeyad]

/wait

[abeyad]

/lgtm api

but waiting on removing uses of this APi

[abeyad]

/assign @jmarantz

[jmarantz]

We'd like to wait before merging till Paul sorts out our internal dependencies. Can we flip this into WiP mode?

[ravenblackx]

We'd like to wait before merging till Paul sorts out our internal dependencies. Can we flip this into WiP mode?

It's already been more than a year - surely Google can manage to do what anyone else would have to do here, just not update to a newer version until they've fixed their internal dependencies to be compatible with that newer version?

[yanavlasov]

We'd like to wait before merging till Paul sorts out our internal dependencies. Can we flip this into WiP mode?

It's already been more than a year - surely Google can manage to do what anyone else would have to do here, just not update to a newer version until they've fixed their internal dependencies to be compatible with that newer version?

@ravenblackx we had a "code yellow" for one of the products that prevented us from replacing the codec due to its risk. We are not blocked any longer and actively working internally on completing the codec migration. We would appreciate understanding on this issue and give us more time to avoid carrying a large patch internally.

[yanavlasov]

/wait-any

[ravenblackx]

We are not blocked any longer and actively working internally on completing the codec migration. We would appreciate understanding on this issue and give us more time to avoid carrying a large patch internally.

I can understand why you'd want that, but anyone else would have to make the choice between "carry a patch, or don't update the version we use until we've fixed our internal issues"; blocking the external fix wouldn't even be an option.

Perhaps as a compromise we could set a date? My view here is that carrying a patch for a short time is really a tiny burden, so treating it as a painful blocker implies that you think you'd be carrying the patch for a long time, which in turn implies that the expectation is to block this for a long time. Once that begins, there will be no incentive to fix it internally rather than "working on something higher priority" because this fix will have no priority, as it costs ~nothing to continue to block the PR (though it's a pain for the PR owner who now has to maintain this PR just as much as Google would have to maintain that hypothetical patch).

If there's a target date at which this cleanup will be committed then the internal fix would at least have a real meaningful priority, as not doing it before the date will cost "now we have to do a patch", and then once it is a patch, if that target isn't met, there'd be an ongoing patch-maintenance cost, ensuring the required updates still have some meaningful priority. (I would still contend that really we should go directly to that latter state like anyone else would have to, but a compromise seems reasonable.)

[ggreenway]

I am fine delaying this, but agree that we should put a date on it.