Introduce tfexec.ErrStateLocked to represent locked state error

[alec-rabold]

Adds parsing for errors where Terraform fails to acquire a state lock. Returns a first-class ErrStateLocked error, including the corresponding LockInfo.

Uses a slightly different LockInfo structure from upstream Terraform:

• Excludes the Info section simply out of difficulty parsing out where that blurb ends
• Treats Created as a string instead of date, mostly because I wasn't sure how to handle the (unlikely) error from time.Parse() in wrapExitError()

Side note: I don't see as much of a use-case for an Unlock() error, but I'm happy to add that in as well.

I've created a mini test-case here: https://play.golang.org/p/aAeRS5yOb7x. I can add some test cases for exit_errors.go if that's preferred though.

(Related to #222)

[hashicorp-cla]

All committers have signed the CLA.

[radeksimko]

This looks like a useful addition, thank you for the PR.

Treats Created as a string instead of date, mostly because I wasn't sure how to handle the (unlikely) error from time.Parse() in wrapExitError()

I think that could be handled the same way as if the error message doesn't match the expression, i.e. just fall through to the generic error.

As for tests - I think it would be nice to have them, but we don't seem to have any unit tests directly testing any of these expressions. I am assuming it's probably because the risk of the expression being wrong here is acceptable - we just fall back to a more generic error.

@kmoe correct me if I'm wrong here about my assumptions about testing - do we want to introduce tests here? I guess the bigger question is whether we treat this as a "compatibility guarantee" in any way as we head towards v1. I'm leaning more towards no as building guarantees on top of scrapped text seems hard 😄

[alec-rabold]

Thanks for taking a look @radeksimko!

I stumbled upon the terraform-exec/tfexec/internal/e2etest/errors_test.go file which looked like a good place to add a test for this as there's already a few in there.

Regarding the date-parsing, it seems the string format isn't 100% consistent after running it through the existing test suite. I'm thinking it may be best to leave that logic out.

Let me know if you folks have any thoughts or concerns there.

[radeksimko]

Thank you for that added test.

This LGTM. I just left a minor suggestion in-line which I'm going to apply, to get it merged now.

[radeksimko]

The test failure is unrelated to this PR.