Refactor wrap/deploy of SAC

[tupui]

Closes #716

The "wrap" terminology has been changed to "deploy". This PR proposes a refactoring of the doc which correct the terminology. I also removed some duplication as to ease future maintenance. I also found it confusing to have multiple times the same info with slightly different explanation.

One thing I think should also be present is the clarification between token::Client and token::StellarAssetClient. But here I actually don't really get the difference 😅

In the doc example, there is this

// Create a client instance for the provided token identifier. If the
// `token_id` value corresponds to an SAC contract, then SAC implementation
// is used.

which to me means that I could just use token::Client. But if I do that, I can just burn but not mint. And with token::StellarAssetClient, I can mint but not burn.

Last thing, I am also not sure if the SAC guide should not be integrated into the SAC page itself.

Let me know how I should modify this. Please feel free to to anything with this PR or push directly on the branch 😃

cc @leighmcculloch

[leighmcculloch]

Thanks for moving this guide forward. I left a couple comments.

[tupui]

Thank you @leighmcculloch for the review. I addressed your suggestions 😃 Let me know if I can do more to help.

[ElliotFriend]

This is a really great PR! Thanks for the excellent additions!

[ElliotFriend]

Hope you don't I pushed a couple commits to your branch:

1. The build fails if there's any markdown syntax errors, so I linted those. (In this case, it was an extra space at the end of a line. Stupid nitpick, i know lol)
2. I added an nginx redirect corresponding to the change in the filename

The PR looks good to me! If @leighmcculloch is happy with it, I'm happy with it!

[tupui]

Thank you @ElliotFriend for the review and the commits. I do prefer such active collaborations.

From my perspective I would still like to have a short description about

One thing I think should also be present is the clarification between token::Client and token::StellarAssetClient

But as I said above, I don't really understand it to explain it myself 😅

This could be kept for a follow up too of course.

[leighmcculloch]

Couple small tweaks otherwise LGTM! Thank you!

[leighmcculloch]

From my perspective I would still like to have a short description about

One thing I think should also be present is the clarification between token::Client and token::StellarAssetClient

We should say I think something along the lines that the token::Client is a client for accessing the functions exposed by any SEP-41 compatible token contract. The token::StellarAssetClient exposes the functions of the Stellar Asset Contract that are not part of SEP-41 and not expected or required to be found on compatible token contracts. So other contracts integrating with SEP-41 token contracts should ideally not dependent on the Stellar Asset Contract's additional functions, otherwise they won't be able to support custom tokens that implement SEP-41.

[tupui]

Oh and so this is why then burn and mint are not doubled in these 2 interfaces, they are exclusive. Got it, I will try to add that tomorrow (off for the day 😅, though feel free to not wait for me). But thanks, I thought I was doing something hacky by using two different clients! (From a pure DX perspective, that would be handy to have a client that would sort of merge both, if that makes sense.)

I think we need to add 2 paragraph: on the Token page discuss the token::Client and on the SAC page the token::StellarAssetInterface. Then on the SAC guide, we can discuss both clients with e.g. the mint/burn example.

[leighmcculloch]

From a pure DX perspective, that would be handy to have a client that would sort of merge both, if that makes sense.

I debated this, and I think it'd be convenient. My reason for not including it is I thought it would end up with folks writing code that uses the Stellar Asset Client everywhere, and never the token client, and so building integrations with tokens that are dependent on Stellar Assets by accident when they otherwise might work fine without the additional functions.

[tupui]

I did a suggestion for the clients. In the end, I only modified the SAC page, as I think it's fitting more. Otherwise the info would have been spread on 2 different pages, then it could be harder to connect the 2 things together.

building integrations with tokens that are dependent on Stellar Assets by accident when they otherwise might work fine without the additional functions

Is it because that could mean additional cost as the WASM would need to pack more code if only the SEP-41 part is needed?

[tupui]

@leighmcculloch @ElliotFriend is there anything else I can help with?

[leighmcculloch]

I pushed a little tweak, will merge once verifying the preview deployment.

[leighmcculloch]

cc @sisuresh

[leighmcculloch]

@tupui Thanks for leading the charge on improving these docs!!!

[tupui]

Thank you all for the help and collaborative work here, really enjoyed the process 😃 🚀