DELETE booking requests fail with 422 error - missing support for request_body in destroy method

[joshuaoliveros]

Describe the bug

The Bookings#destroy method doesn't support passing a request_body parameter (e.g., for cancellation_reason), and the underlying ApiOperations::Delete#delete method hardcodes payload: nil. This causes 422 Unprocessable Entity errors when calling the Nylas API to delete bookings.

When HTTParty sends a DELETE request with payload: nil, it doesn't properly set the Content-Type: application/json header, causing the Nylas API to reject the request. Additionally, there's no way to pass optional body parameters like cancellation_reason which are supported by the Nylas Scheduling API.

To Reproduce

require 'nylas'

nylas = Nylas::Client.new(
  api_key: ENV["NYLAS_API_KEY"],
  api_uri: ENV["NYLAS_API_URI"]
)

# This fails with 422 Unprocessable Entity error
nylas.scheduler.bookings.destroy(
  booking_id: "booking-123",
  query_params: { configuration_id: "config-456" }
)

# Error: Nylas::NylasApiError - Unprocessable Entity
# Stack trace shows the error originates from:
# /lib/nylas/handler/http_client.rb:333:in `handle_failed_response'
# /lib/nylas/handler/api_operations.rb:149:in `delete'
# /lib/nylas/resources/bookings.rb:69:in `destroy'

Additionally, there's no way to pass a cancellation_reason:

# This SHOULD work but isn't currently supported
nylas.scheduler.bookings.destroy(
  booking_id: "booking-123",
  query_params: { configuration_id: "config-456" },
  request_body: { cancellation_reason: "Meeting no longer needed" }
)
# Error: unknown keyword: :request_body

Expected behavior

1. DELETE requests should work without throwing 422 errors when no request body is needed
2. The Bookings#destroy method should accept an optional request_body parameter to support API features like cancellation_reason
3. The ApiOperations::Delete#delete method should default to payload: {} instead of payload: nil to ensure proper Content-Type headers are sent

SDK Version:

nylas gem: 6.7.0

Additional context
This issue appears to have been introduced in version 6.5.0 when the SDK switched from rest-client to httparty.