Update Documentation for Protocol Support in DiceDB

[pratikpandey21]

Description

Update the DiceDB documentation to comprehensively cover the different protocols that DiceDB supports, including RESP, HTTP, and WebSocket (WS). The documentation should provide clear guidelines on how customers can leverage each protocol for various use cases, highlighting their features, advantages, and potential applications.

Requirements:

Comprehensive Protocol Documentation:

• Provide an overview of all protocols DiceDB supports: RESP, HTTP, and WebSocket (WS).
• Include a detailed explanation of the capability available with each protocol(eg, if all commands are supported)
• Highlight each protocol's benefits and unique features and when it is most appropriate to use one over the others.

E.g.:
RESP: Low-latency, high-performance use cases where clients communicate directly with DiceDB.
HTTP: Webhook integrations, SSE-based real-time updates, and RESTful interactions.
WebSocket (WS): Applications requiring low-latency, bidirectional communication, such as live updates or collaborative environments.

[pratikpandey21]

Depends on #553 and #555

[KaviiSuri]

@pratikpandey21 i'd love to help out on this once the dependencies are done

[pratikpandey21]

Thanks Kavi!

[lucifercr07]

@KaviiSuri would you like to take this up? We're done with implementation of HTTP we can start on that.

[KaviiSuri]

@lucifercr07 yes, I’ll go ahead with it now. Thanks for pinging me

[KaviiSuri]

Will try to get a draft ready by eod tomorrow

[KaviiSuri]

went through the implementation, will publish PR this weekend

[KaviiSuri]

@lucifercr07 @pratikpandey21 here is a PR for the docs: DiceDB/docs#114 , would love to hear your feedback on this.

[KaviiSuri]

My Current Concerns about the implementation (added here for sake of trackability)

1. We use SSE with body, while the Web Standard for SSE (EventSource) doesn't really support it. It would be better for developer experience if we just used query params for QWATCH (and other SSE backed commands)
2. it seems like enabling HTTP 2.0 dice would allow it to server more SSE without browser limitations on number of connections. Enabling HTTP 2.0 is automatic in go post 1.6, we just need to use TLS since 2.0 requries TLS. go net/http will deal with version negotiation itself
3. We do not allow for CORS configuration right now, but we need to have it configurable through our config file for any real world use-case involving browsers querying the db.