[SEP-38] Add buy/sell delivery method to quote api response

[JiahuiWho]

Added to both POST /quote and GET /quote response

Context
Current SEP-38 quote API response doesn't include the buy/sell delivery method, even though it's stored in the DB
https://stellarfoundation.slack.com/archives/C036T11AY84/p1719603232852849

[lijamie98]

Please feel free to merge after the comments are taken care of.

[JakeUrban]

can you provide a detailed description of why you're proposing this change?

[JiahuiWho]

I will update the desc. For your reference @JakeUrban More context can be found here :
https://stellarfoundation.slack.com/archives/C036T11AY84/p1719603232852849

[JakeUrban]

Can you update the version number and updated at field at the top of the document?

[JakeUrban]

When we make changes to the protocols, we need to be mindful that these APIs are implemented by various businesses in the ecosystem, not just the anchor platform.

We ideally shouldn't even make changes to the protocol's without initiating discussion with the relevant ecosystem businesses, but at the very least we need to publicly document our rationale for making changes.

[JiahuiWho]

Sorry I am confused. I do understand how protocol change will impact out partners. In my opinion there's not a solid reason that we have to make this change or we must not, but I thought an agreement to proceed has been reached according to the slack discussion. Do you wish to hold off the change and reach to partners first?

[JakeUrban]

Sorry for the confusion, I do think we can proceed here without engagement from the ecosystem since we're adding optional response attributes, so all existing implementations would still be compliant. I just wanted to avoid us merging changes to the protocols without publicly documenting the rationale.

[JiahuiWho]

I updated desc to include the rationale according to the slack discussion. Let me know of it looks good to you.

[JakeUrban]

Current SEP-38 quote API response doesn't include the buy/sell delivery method, even though it's stored in the DB

This description doesn't quite give enough information for someone that isn't a part of the anchor engineering team. I would try to structure descriptions like this:

1. What is the problem?
2. What is the proposed solution?
3. Are there any comments / concerns with the proposed solution that you're looking for feedback on?

I would specifically leave out any implementation specifics of the anchor platform. So in this case, the description could look like this:

The POST /quote and GET /quote API responses do not include the buy_delivery_method or sell_delivery_method key-value pair that was provided in the associated POST /quote request, which forces clients to save this information in their own data store if they later need to know how to deliver funds. This doesn't make a lot of sense, because clients can fetch all other quote information using the GET /quote/:id.

This PR adds the sell_delivery_method and buy_delivery_method attributes as optional response parameters to GET /quote/:id and POST /quote endpoints, allowing the client to only store the quote ID on their end. When it is time to transfer funds associated with the quote, the client can then fetch the delivery method using the GET /quote/:id endpoint.

Adding these response parameters as optional attributes ensures any existing implementations are still compatible with the specification.

[JakeUrban]

Approved with some minor edits!

[lijamie98]

LGTM