Feature: S3 connection method

[cap10morgan]

Closes #450

Commit 7efcd2f is the heart of this PR.

No tests yet b/c testing S3 is a little tricky. If folks feel strongly there should be some before merging I can figure out a good way to test this locally w/o actually connecting to S3.

It works in my REPL, though! ;)

[cap10morgan]

Converted to draft b/c I remembered there's one thing I still need to finish in here. Will ping when it's ready for full review.

[cap10morgan]

The last commit (971dab8) is unrelated and I'm happy to split it out into its own PR if desired. But I ran into a common test failure here in one of our load tests where the loaded ledger's t is lower than the one we were building up in memory. I added a new test-utils fn that tries to keep loading until we get a ledger w/ a db t of at least that value. So hopefully that will make those tests more reliable.

[cap10morgan]

OK @fluree/core this is ready for review

[zonotope]

🪣

[bplatz]

failure here in one of our load tests where the loaded ledger's t is lower than the one we were building up in memory

If this is after a fluree/commit! which is deref'd then this is a bug that should be high priority and get a new ticket. There should never be a return from commit! until persistence is guaranteed. Perhaps this is specific to a testing tool... not sure, but please advise.

[cap10morgan]

failure here in one of our load tests where the loaded ledger's t is lower than the one we were building up in memory

If this is after a fluree/commit! which is deref'd then this is a bug that should be high priority and get a new ticket. There should never be a return from commit! until persistence is guaranteed. Perhaps this is specific to a testing tool... not sure, but please advise.

Just to make sure I'm understanding things correctly:

This is a (deref'd) commit! followed by a load. If I understand things correctly, the load will use the latest pushed head commit when it is called, but push is async. So in these quick commit! then load scenarios in tests, it's possible to load before the push is complete. Does that seem right / expected?

[bplatz]

That's OK then... as the name service is intentionally async. We discussed creating an option for name services that could allow ones that can more easily support it to be synchronous and block... but e.g. IPNS as a name service really needs to be async.

However, the return from commit! should be a new db address... in this case there is no need to use the name service, as the only thing it does is tell us the db address that we should already know with the returned db.

I'd suggest any tests with this sort of dependency opt to not use the name service unless there is something specific about the name service itself they are testing.