Quick Start 1 - suggested update

[leggetter]

This is an update to the first quick start that does the following:

1. Moves setup to using cURL requests: creates a conversation and joins a user to that conversation. This means we can avoid the client-side logic to handle this. It also means it may better map with the target usage where customers will want to do this on the server.
2. Introduces stubbed out login - lets you hard-code a JWT for the first user and adds potential to extend for additional users.
3. Adds many more headers. Also, uses numbered headers since I've had conversations with a few people who've suggested having numbered steps in tutorials makes them easier to follow.
4. Add key concepts to the top of the quick start. I'm wondering if these should actually be in the GitHub repo README?

If we agree on this flow then we should update the Android and iOS quickstarts to do the same. We should also decide what the next quickstarts should be. I've created #2 to track that.

[AlexLakatos]

Added a few minor updates in #4 .

[kapekost]

I think we need to note in a few places the difference between display_name and name above you're using the name so the code cannot run 2 times (they will get get an error for existing conversation name)

the sdks are now aligning to switch to support display_name, but it's not in all versions in all sdks yet, so maybe you should expect a bit of confusion there till it gets clear to everyone.

I will give a reminder here of what's the difference, just in case:

newConversation({name:'name, display_name:'display_name'}) both of them are optional if you specify a name, CS will use it, but it has to be unique. if you don't specify the name, the CS will assign one for you

if you specify a display_name, CS Will accept it and will reply including it (we have one merge pending on this in CS) if you don't specify a display_name the CS will do nothing about it

[leggetter]

@kapekost - we've removed the newConversation from the client-side code completely. We now create the conversation on the server. We also reference the conversation by ID rather than name.

Does that remove your concerns?

[kapekost]

@leggetter nope, for this, it doesn't make a difference where are you creating the conversation from, :) your curl calls use name

if you use name:"name" you will start getting errors if you run it more than 1 times.. (name already exists)

then in the SDK you will do getConversations => conversation.name

but according the above, if you create the conversation with display_name (either curl or sdk), you will need: getConversations => conversation.display_name

I think it's very bad timing to talk about that, since the sdks/cs are in the middle of aligning this, so maybe for you now, it's ok to keep it in your minds for now, so it will be easier to solve upcoming "conversation-name" related issues/questions

[AlexLakatos]

@leggetter added #5 to remove the name and nexmo-chat from the QS. Looking through it, we only referenced it in the text, and not the code. We're using CONVERSATION_ID throughout the code anyway, I thought we might not want to risk the user running the Setup command twice and getting an error.