api: Use 'direct' instead of 'private' in POST /messages, when supported

[supra08]

Fixes: zulip#5725

[dashwave]

Build Status	✅ Successful
Build Time	3m50s
📱 Emulation Link	https://console.dashwave.io/emulator/1704/preview?device=emulator
Logs	See Logs

[supra08]

@dashwave /review

[dashwave]

Title: Use 'direct' Messaging Type When Supported, Maintain Compatibility for Legacy Servers

What is this?

This pull request addresses the deprecation of the private message type in favor of direct in the Zulip API. This change ensures compatibility with servers supporting direct messages while maintaining backward compatibility with legacy servers that still rely on private. By leveraging the zulipFeatureLevel, the application dynamically determines which message type to use, ensuring a seamless transition and support across different server versions.

Changes

Added Features:

1. Enhanced Message Sending Logic in sendMessage.js:
   • Updated sendMessage function to dynamically adjust message type between direct and private based on zulipFeatureLevel.
   • Ensures backward compatibility by reverting to private when zulipFeatureLevel is below 174.

Code Changes:

1. In src/api/messages/sendMessage.js:

   • Modified params destructuring to include zulipFeatureLevel.
   • Introduced conditional logic to determine the message type based on server capability.

2. In src/outbox/outboxActions.js:

   • Integrated getZulipFeatureLevel to fetch the feature level of the server.
   • Updated trySendMessages to leverage the new type differentiation logic for outbound messages.

3. In src/sharing/ShareWrapper.js:

   • Included zulipFeatureLevel in the component's props.
   • Adjusted message construction in handleSend to utilize the appropriate message type, ensuring compatibility when sharing content.

Documentation Updates:

1. Updated Private Message Handling Documentation:
   • Not included in this PR but should be noted for future documentation updates to reflect the changes in message type handling.

---

Pull Request Review

Code Quality

• The refactored code introduces conditional logic that smartly switches between private and direct message types based on the zulipFeatureLevel. This approach maintains clarity and succinctness, adhering to clean coding standards.

Integration

• The code changes smoothly integrate with the existing code base. The preservation of backward compatibility ensures that the application supports various server configurations without additional client-side configurations.

Documentation

• While the code changes are accompanied by detailed comments explaining the rationale for the conditional logic, future documentation should explicitly mention the feature-level dependencies and behavior changes in message sending.

Testing and Verification

• Ensure to verify the changes across different server versions to confirm seamless functionality, especially when testing the handling of zulipFeatureLevel above and below 174.
• Additionally, automatic tests should be updated or introduced to cover these conditional paths for comprehensive coverage.

---

These changes are a step forward in embracing evolving server capabilities while still extending support to legacy systems, making the application robust and adaptive.