289 feature dynamodb data accessor structure for emily api

[AshtonStephens]

Use the following template to create your pull request

Description

Add database access code to the Emily API.

This PR adds the following changes:

• Context structure
• Deposit, Withdrawal, and Chainstate
  • Database access functions
  • Database structures
  • Handler logic for GET and POST requests

I'm not adding tests here because they're going to take longer than a day or so, and getting this out will unblock Setbern's work on the web interface.

[djordon]

I'm not adding tests here because they're going to take longer than a day or so, and getting this out will unblock Setbern's work on the web interface.

I think you should add tests to this PR (or each of the smaller ones if you break it up). If you feel it's okay enough to unblock Setbern now, we could just ask him to pull down this branch and work off of that. But to merge we should add tests¹.

---

Should this PR be broken up.

(I forget where this question was asked, just gonna respond here)

I feel like the answer is something like "not for this PR, but yes going forward". Well, this is already just a draft so I could also see myself coming out the other way on this one.

My reasoning: I feel like large PRs are quite taxing on the reviewer, much more so than a sequence of smaller ones with the same code (usually because they are packaged coherently). This usually translates into a better review where we are more likely to catch stuff. Maybe I'm alone in my feeling here, curious about what other people have to say.

Footnotes

1. I recently broke this rule in https://github.com/stacks-network/sbtc/pull/300 😞. But this was mainly because adding a test was part of another larger ticket that was about adding tests. ↩

[AshtonStephens]

@djordon; Oh, just saw your "PR should be broken down" comment. Roger that;

[AshtonStephens]

Should this PR be broken up.

(I forget where this question was asked, just gonna respond here)

I feel like the answer is something like "not for this PR, but yes going forward". Well, this is already just a draft so I could also see myself coming out the other way on this one.

My reasoning: I feel like large PRs are quite taxing on the reviewer, much more so than a sequence of smaller ones with the same code (usually because they are packaged coherently). This usually translates into a better review where we are more likely to catch stuff. Maybe I'm alone in my feeling here, curious about what other people have to say.

I agree with this reasoning to break it up. There are a lot of lines of code here; I thought I'd be able to get away with it because the majority of the lines of code are object definitions that are already defined in the LLD / implicitly defined by the resources, but on reflecting it doesn't really matter when reviewing because it's all content you need to look at.

[djordon]

Looks good. Just run cargo fmt in the emily directory and then feel free to merge.