feat(orm): gRPC codes for save errors

[aaronc]

Description

Ref: #11088. First PR of several to add gRPC error codes and make sure that errors are a well-defined part of the API.

Also introduces Cucumber-style BDD acceptance tests into the SDK via https://github.com/regen-network/gocuke.

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• included the correct type prefix in the PR title
• added ! to the type prefix if API or client breaking change
• targeted the correct branch (see PR Targeting)
• provided a link to the relevant issue or specification
• followed the guidelines for building modules
• included the necessary unit and integration tests
• added a changelog entry to CHANGELOG.md
• included comments for documenting Go code
• updated the relevant documentation or specification
• reviewed "Files changed" and left comments if necessary
• confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

• confirmed the correct type prefix in the PR title
• confirmed ! in the type prefix if API or client breaking change
• confirmed all author checklist items have been addressed
• reviewed state machine logic
• reviewed API design and naming
• reviewed documentation is accurate
• reviewed tests and test coverage
• manually tested (if applicable)

[peterbourgon]

Please don't introduce new testing frameworks to the project.

[aaronc]

Why?

[peterbourgon]

There's no reason for it. Everything here is equally well expressed as conventional table-based Go unit tests.

[peterbourgon]

Each new dependency added to go.mod must be default deny. The onus is on the author to justify its value.

[aaronc]

The goal is readability. We've decided internally to try this type of testable documentation. If it doesn't provide value, we won't continue with it

[tac0turtle]

It might be useful to get an ADR on testing up and which way things are going. We all understand there is an issue with testing in the cosmos-sdk that leads to messed up ci pipelines and not having full coverage.

I thought there was agreement on this from the Regen side, but seems there are conflicting opinions.

[peterbourgon]

I have clearly misunderstood the purpose of PRs in this project. My apologies. I'll refrain from commenting or contributing any further.

[aaronc]

1. https://github.com/regen-network/gocuke is a repo of 62 (non-reviewed?) commits by Aaron. If we add this to the SDK, we need to reduce the bus factor first audit it (or at least understand it).

Folks on the regen ledger side have looked into this more and that is where our devs are more aligned around this approach @marbar3778. We can prepare something a bit more formal if that helps. Although the reality is we don't usually do too thorough of an audit of 3rd party test dependencies as is...

2. The acceptance tests should test that code matches spec, where "spec" is generally an agreed-upon document in English language. We don't have this doc yet for ORM (Marko and I will try to work with Aaron on that), it seems now that these tests almost are the spec itself, is that what BDD precognizes?

That's the point. There is no English language spec. That's precisely what this introduces

[aaronc]

@marbar3778 let's continue discussion in #11356. This has two approvals but I will hold off on merging until I get your approval @AmauryM. Will be in touch with both of you around how we want to move forward

[robert-zaremba]

For the matter of the fact: most of the Cosmos SDK tests are not readable. Cucumber style tests are way more readable (few orders of magnitude +1).

[codecov]

Codecov Report

Merging #11386 (05dddf0) into master (4081bc3) will decrease coverage by 0.04%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master   #11386      +/-   ##
==========================================
- Coverage   66.03%   65.99%   -0.05%     
==========================================
  Files         719      713       -6     
  Lines       73920    72871    -1049     
==========================================
- Hits        48813    48091     -722     
+ Misses      22053    21807     -246     
+ Partials     3054     2973      -81     

Impacted Files	Coverage Δ
orm/model/ormtable/table_impl.go	59.92% <100.00%> (+2.24%)	⬆️
orm/model/ormtable/unique.go	44.09% <100.00%> (+2.36%)	⬆️
db/memdb/db.go
db/rocksdb/iterator.go
db/badgerdb/db.go
db/memdb/iterator.go
db/prefix/prefix.go
db/rocksdb/db.go
db/rocksdb/batch.go
db/version_manager.go
... and 8 more

[amaury1093]

Approving an putting automerge! Let's 🥒

I think the english spec -> acceptance tests -> code process is too optimistic, and I agree with Aaron we've been more doing in practice in the past months: code -> tests -> spec/ADR. Probably gocuke will help here with the latter process.

I think this PR a good case study to see if it's useful. I still have doubts about gocuke, i'll need to see it more in action. But I also encourage other people to give feedback. The ideal feedback would be from users of the ORM (once we release it). If it's useful to them, then it's a win. If not, then let's discuss again.