fix inconsistencies of dolt checkout and pull commands

[jennifersp]

This PR fixes inconsistent behaviors of Dolt CLI against Git commands AND of Dolt SQL against Dolt CLI commands.

Inconsistencies between Dolt CLI and Git:

• dolt checkout new_branch: checking out a new branch without -b flag. If there is a remote branch with matching name, sets upstream.
• dolt checkout -b new_branch: if there is a remote branch with matching name, it does not set upstream.
• dolt pull and dolt pull remote_name: each gives separate errors when run on a branch that does not have upstream

Inconsistencies between Dolt CLI and Dolt SQL:

• dolt pull should match dolt_pull()
• dolt_checkout() and dolt_push() should set upstream that persists outside of sql session (added skipped tests)

[fulghum]

Are you sure about this one?

dolt push origin new_branch: if remote name and branch name is given, it sets upstream without --set-upstream flag

I didn't see anything in the git docs about automatically setting the upstream without having to supply --set-upstream and a quick test with git didn't record an upstream for me. Let me know if you can repro git setting the upstream this way.

[fulghum]

Lots of good fixes in this PR!! Good job digging in deep and finding all these details. No major concerns from me; let me know if any comments don't make sense.

Two larger comments/thoughts popped out at me while reviewing, too:

• there is a LOT of duplication between the CLI path and SQL path! 😊 It'll be hard to keep those exactly in sync, just like you found. There's an interesting question about when to refactor a little bit more while we're in here and see if we can chip away at the duplication. For example, with dolt pull, it seems like there might be some low hanging fruit around combining the code paths. Not necessary for this PR, but something to think about as we're in this code.
• we should talk more about layers of testing between BATS and the enginetests. I both are super important, and could be a good conversation to talk through a mental framework for what to test where.

[fulghum]

interesting that the SQL path doesn't persist the tracking metadata. have you already figured out why that is, or found any clues?

Does this mean if a customer has to restart their sql-server, they'll lose all this tracking metadata? Or is it just that the metadata can't be read outside of the SQL path?

Given that we are so focused on the SQL experience, I think this one is worth fixing quickly, but totally fine to tackle it in a separate PR.

[jennifersp]

We store upstream tracking metadata in repo_state.json file, and we do not have access to that file from inside the SQL session. As long as, user is in the same session, any changes on upstream tracking works fine, but once out of the session, the changes made inside the session will not be saved since we cannot access the repo_state file

[fulghum]

Thanks for the extra context. If we don't have a tracking issue for this, could you create one? Seems like something that will confuse/surprise customers and would be great to close this gap before someone falls in it.

[fulghum]

Nice work! Just one comment on a small tweak for an error message to match Git's response a little closer.