enhancement(http): unifying http query parameters

[sainad2222]

Summary

Unifying http query parameters while maintaining backward compatibility. Refer to this for approach

Change Type

• Bug fix
• New feature
• Non-functional (chore, refactoring, docs)
• Performance

Is this a breaking change?

• Yes
• No

How did you test this PR?

sources:
  prom_source:
    endpoints:
      - "http://localhost:9090/federate"
    honor_labels: true
    scrape_interval_secs: 60
    scrape_timeout_secs: 45
    query:
      match[]:
        - '{job="node1"}'
    tls:
      verify_certificate: false
      verify_hostname: false
    type: prometheus_scrape

sinks:
  output:
    type: "console"
    inputs: ["prom_source"]
    target: "stdout"
    encoding:
      codec: "json"

Does this PR include user facing changes?

• Yes. Please add a changelog fragment based on our guidelines.
• No. A maintainer will apply the "no-changelog" label to this PR.

Checklist

• Please read our Vector contributor resources.
  • make check-all is a good command to run locally. This check is
    defined here. Some of these
    checks might not be relevant to your PR. For Rust changes, at the very least you should run:
    • cargo fmt --all
    • cargo clippy --workspace --all-targets -- -D warnings
    • cargo nextest run --workspace (alternatively, you can run cargo test --all)
• If this PR introduces changes Vector dependencies (modifies Cargo.lock), please
  run dd-rust-license-tool write to regenerate the license inventory and commit the changes (if any). More details here.

References

• Closes: Unify handling of query for HTTP-based components that support it #12073

[kayayarai]

No docs review required

[sainad2222]

@jszwedko Gentle ping :)

[jszwedko]

Nice! Thanks for this improvement @sainad2222 ! I think the code looks good. It is a bit unfortunate that the docs don't clearly show that query can be a key/value or key/values. I expect users may end up confused. If you feel up to it, you could try to dig into the docs generation to see if you can adjust it, but I don't think that needs to block this since the current docs also don't really clearly show how the query option is used.

I left a couple of other minor comments below.

[jszwedko]

It seems like these examples aren't rendering properly on the docs, but that seems to be an existing issue so we don't need to block this.

However, could we add to the examples an example of specifying a single value? I think all existing examples in query_examples() for all of the sources only show specifying an array of values.

[pront]

As an alternative, you can hand write a small "how it works" section on query params

[sainad2222]

Hi,
@jszwedko This particular example has single value(for elasticsearch sink) only. Did you mean for http_client source? If Yes, I made changes for that now
@pront Where can I write this "how it works" for query params. Any existing reference I can follow? Will it go in .rs files or .cue files?

[jszwedko]

Technically this should indicate that either a string or [string] can be used, but I'm not sure the current cue schema supports this (or if the code that generates the cue from the struct definitions does) 🤔