Create tip tap documents

[calebbourg]

Description

This PR adds the creation of Tiptap documents when a new coaching_sessions record is created.

It also refactors and modifies a few other patterns in the application.

Note: This one is somewhat beefy. It may be helpful to review commit by commit.

GitHub Issue: Part of epic issue #96

Changes

• Refactors how errors are handled, categorized, and passed upward through the application layers.
• Adds network calls to Tiptap to create new documents when a coaching session is created
• Adds/updates documentation and logging

Testing Strategy

I tested this using Utoipa
TIP_TAP_URL=https://{your tiptap app ID}.collab.tiptap.cloud TIP_TAP_AUTH_KEY={your tiptap API key} cargo run

1. Start the server adding new environment variables
2. dispatch a POST /coaching_sessions request from Utoipa with a body similar to:

{
  "coaching_relationship_id": "d0ae575a-ca20-4cfe-ab79-5092f0cdc0aa",
   # pay special attention to the datetime format
  "date": "2024-12-19T10:23:45",
  "timezone": "string"
}

Concerns

Name Changes

• I made a few name changes. The biggest one being changing the convention of "error types" to "error kinds". I did this because I found myself becoming somewhat confused reasoning about an error's "type" as a business logic concept vs an error's Type as a Rust type system concept. I decided "kind" based on some other projects I have seen and because I feel it establishes a clear distinction.

What's Next

• Clarify and improve datetime formats and requirements
• Validating that two coaching sessions cannot have the same date and time for a given user (wouldn't make sense to double up)
• Potentially save document names as part of the coaching_sessions record
• write unit tests

[jhodapp]

Looking really great Caleb, thank you. I'm very excited about having this functionality in place.

Left several suggestions, questions and reflections. Let me know if you have any questions.

[jhodapp]

I'd like to suggest turning the 409 into some TipTap return code type that we can reuse throughout that codifies TipTap's return codes that we use? That'll help us better document what the return code means with a name. Maybe an enum that stores an u16?

[calebbourg]

I think that's a great idea. Let me think a bit on where that might live? At some point I think we'll likely have a dedicated Tiptap module that will encapsulate everything Tiptap REST API related. An enum describing the various semantic meanings of Tiptap's HTTP statuses would definitely belong there. I decided against preemptively defining a module like that in this PR as I figured the design would be premature.

[jhodapp]

Yeah that makes sense. I guess that's why I am suggesting for now, just a really simple moving of the TipTap-related items into a file like tiptap_client.rs or something is helpful but not a big lift. It's helpful to separate your TipTap functions out from coaching_session.rs but not have to restructure it as a fancy struct just yet. I'm open to your thoughts here.

[calebbourg]

Yeah that totally works. I'll make that update.

[calebbourg]

Added a tiptap module in 82fe4be
Decided to hold off on defining the enum for responses as it will require me to map all possible reqwest::STATUS_CODE variants to whatever enum we define. We can come back around when we have a better idea of what the semantic meaning of each is for tiptap.

[jhodapp]

No problem, thanks for the explanation.

[jhodapp]

A couple of enhancements for the CLI —help console output.