Receiver Side ACL plugin and Chain Engines example

[livingshade]

Why are these changes needed?

This PR includes the following change:

• A receiver side ACL plugin, that can intercept request and return an error code, bypassing the server logic.
• A example of chaining multiple engines, with document.
• A fix about upgrade logic, which tries to flush all engines iteratively until nothing left. This enables engines that, when being flushed, send other request backwards. Previous implementation only requires requests to be sent in dataflow order.
• Some other minor fixs.

Checks

• [ ✅] I've run scripts/clippy.sh to lint the changes in this PR.
• [ ✅] I've included any doc changes.
• Testing Strategy
  • [ ?] Release tests
  • [ ] This PR is not tested :(

[crazyboycjr]

@libertyeagle Could you double-check if the changes in src/phoenixos/src/runtime/upgrade.rs make sense to you? I think currently it implies that we should trust the engine developers to never block the runtime (given that we already trust engine developers, so it should be fine?) Would there be any other possibility that the flushing stage was blocked indefinitely?

[libertyeagle]

@libertyeagle Could you double-check if the changes in src/phoenixos/src/runtime/upgrade.rs make sense to you? I think currently it implies that we should trust the engine developers to never block the runtime (given that we already trust engine developers, so it should be fine?) Would there be any other possibility that the flushing stage was blocked indefinitely?

LGTM! Thanks.