Make release build not be special

[jonhoo]

Currently, we gate a number of things in the code, including what it actually builds on debug_assertions (~= --release). This has served us well so far, but it can be pretty confusing. Instead, I think what I want is as follows:

• cargo run and cargo run --release should do the same thing
  • That thing should be to run in non-Lambda mode.
  • Lambda mode should be enabled using --as-lambda (or a lambda subcommand; either is fine).
  • Should respect USE_DYNAMO.
    • I think there's an argument for not including local support when building --release?
      • If so, fail if USE_DYNAMO isn't set with --release.
  • Note that prod deployment configuration will need updating!
• cargo test and cargo test --release should do the same thing
  • That thing should be to run tests against Backend::local
  • The same tests with Backend::dynamo should be ignored.
    • Bonus points if setting USE_DYNAMO un-ignores them (hard w/o Add ability to ignore tests at runtime. rust-lang/rust#68007).
  • Tests are grouped as {local, dynamo}::testname rather than testname::{local, dynamo}.
    • Bonus points if test logic still lives within the appropriate mod (e.g., ask tests in mod ask).
• A new (ignored by default) set of tests which:
  1. Run the equivalent of cargo run --as-lambda (probably using OnceLock to share b/w tests).
  • We'll probably want to pull out the main logic from the binary here.
  2. Run similar (ideally the same without duplicating) tests as cargo test, but invoking the API directly.
  • It should respect USE_DYNAMO.
  • It's possible to have it not use --as-lambda.
    • Or maybe those are just another set of tests?
  • I suspect the trick here will be to add a third Backend that just uses reqwest.
• A new (ignored by default) integration test, say tests/e2e.rs, which:
  1. Runs npm run dev (or npm run build + hosts via axum or something).
  2. Runs cargo run --as-lambda with USE_DYNAMO=local.
  3. Starts a browser (probably chromium since we'll want multiple sessions).
  4. Uses fantoccini to access the frontend.
  5. Runs tests like:
  • Starting an event gives you a URL with an event + secret.
  • Host can ask a question and it shows up.
  • Clicking the "share" button copies the URL without the secret.
  • Using that URL, a visitor can ask a question, which then shows up on both host + guest.
  • Host can mark a question as hidden, and it's no longer shown to guests.
  • Host can mark a question as answered, and it goes to the bottom.
  8. Bonus points if:
  • It can also be run without --as-lambda.
  • It respects USE_DYNAMO.

[rustworthy]

So #218 suggest the lambda vs normal runtime splitting, where the core logic goes to the library and then we got a default bin and a lambda-runtime one.

This PR with end-to-end tests setup relies on the app's logic being in the lib. It utilizes fantoccini and also include the first end-to-end test covering the following "host" story:

• app user (host) can see the welcome page;
• app user (host) can start an event and they are given a URL with an event + secret;
• clicking the "share" button copies the URL without the secret;
• there are initially no questions related to the event;

I will move the mentioned PR to this repository once we handle #218.

jfyi: the Belarusian puppet show is called Batlejka