Naming inconsistencies for HTTP filters

HTTP APIs follow the convention:

- For aggregated APIs (non-streaming): No qualification is present in the names. eg: `HttpRequest`, `HttpResponse`.
- For async streaming APIs: We prefix with `Streaming`. eg: `StreamingHttpRequest`, `StreamingHttpResponse`
- For blocking streaming APIs: We prefix with `BlockingStreaming`. eg: `BlockingStreamingHttpRequest`, `BlockingStreamingHttpResponse`

However, we only provide ways to add async streaming filters, so we drop the qualification in the name. eg: `TracingHttpServiceFilter` extends `StreamingHttpService` but it does not have a name qualification according to the above convention. The rational is to reduce naming verbosity at the cost of not following the conventions.

Not following conventions can cause confusion for users and we should revisit to see if we can reduce this confusion.

The issue does not name specific files, tests, or entry points. Start by inventorying the HTTP filter and service names against the stated aggregated, async-streaming, and blocking-streaming conventions. Done requires an agreed naming direction and consistent handling of the affected filters.

Written by the indexing model from the issue text.