Fix protobuf use case document

[bananaaggle]

Now we have protobuf inputformat, and protobuf parser will be deprecated. So we should change document to follow it. Actually, because of 10647, supervisor properties with parser not work in 'Load data' tab in frontend, as described in 11537.

This PR has:

• been self-reviewed.
  • using the concurrency checklist (Remove this item if the PR doesn't have any relation to concurrency.)
• added documentation for new or modified features or behaviors.
• added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
• added or updated version, license, or notice information in licenses.yaml
• added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
• added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
• added integration tests.
• been tested in a test Druid cluster.

[suneet-s]

LGTM! Thanks @bananaaggle

[suneet-s]

@bananaaggle Do you think you could take a stab at fixing the web-console to use the inputFormat instead of the parser in a future change? I don't know a lot about front-end coding but that would be awesome for people to be able to use the UI instead of having to hand craft the ingestion spec. Thanks again for all your contributions!

[bananaaggle]

@bananaaggle Do you think you could take a stab at fixing the web-console to use the inputFormat instead of the parser in a future change? I don't know a lot about front-end coding but that would be awesome for people to be able to use the UI instead of having to hand craft the ingestion spec. Thanks again for all your contributions!

Actually, all data formats in core extension have been adapted to inputformat. Only one thrift contrib-extension does not have implementation which is in processing in 11360. So in next release, users won't meet this trouble because them can use inputformat to ingest data with all formats. If you mean we should support parser in UI, I think it's easy to change front-end code and I can do it. But Because parser will be deprecated, so it's not necessary supporting it in front-end(new users will not use it through UI if we change user guide). If you think it's necessary to fix it for some old users, I'm glad to make this change.

[suneet-s]

@bananaaggle Do you think you could take a stab at fixing the web-console to use the inputFormat instead of the parser in a future change? I don't know a lot about front-end coding but that would be awesome for people to be able to use the UI instead of having to hand craft the ingestion spec. Thanks again for all your contributions!

Actually, all data formats in core extension have been adapted to inputformat. Only one thrift contrib-extension does not have implementation which is in processing in 11360. So in next release, users won't meet this trouble because them can use inputformat to ingest data with all formats. If you mean we should support parser in UI, I think it's easy to change front-end code and I can do it. But Because parser will be deprecated, so it's not necessary supporting it in front-end(new users will not use it through UI if we change user guide). If you think it's necessary to fix it for some old users, I'm glad to make this change.

I misunderstood when I wrote my last comment - I thought the web console was generating a deprecated parse spec when users selected protobuf, avro, etc. I agree with you that since the parser will be deprecated, it's not necessary to support it in the front-end.