feat: Add decorate package to set rate limit headers

[blaine-arcjet]

This is the first pass at adding a decorate package that allows users to add RateLimit and RateLimit-Policy headers given an ArcjetDecision.

This follows the draft spec at https://ietf-wg-httpapi.github.io/ratelimit-headers/draft-ietf-httpapi-ratelimit-headers.html which has gone through a few iterations and will probably receive more updates soon, as it expired in December 2023.

This implementation requires some service changes to add fields to the protobuf.

Closes #38
Closes #40 (we'll be able to add other decoration functions to this new package)

[trunk-io]

😎 Merged successfully - details.

[socket-security]

👍 Dependency issues cleared. Learn more about Socket for GitHub ↗︎

This PR previously contained dependency changes with security issues that have been resolved, removed, or ignored.

Ignoring: npm/@eslint/[email protected], npm/@humanwhocodes/[email protected], npm/@humanwhocodes/[email protected]

View full report↗︎

Next steps

Take a deeper look at the dependency

Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support [AT] socket [DOT] dev.

Remove the package

If you happen to install a dependency that Socket reports as Known Malware you should immediately remove it and select a different dependency. For other alert types, you may may wish to investigate alternative packages or consider if there are other ways to mitigate the specific risk posed by the dependency.

Mark a package as acceptable risk

To ignore an alert, reply with a comment starting with @SocketSecurity ignore followed by a space separated list of ecosystem/package-name@version specifiers. e.g. @SocketSecurity ignore npm/[email protected] or ignore all packages with @SocketSecurity ignore-all

[blaine-arcjet]

Due to our deny caching, the reset value may be "stuck" until the window has passed. This seems to be okay as per the spec:

Consider that service limit might not be restored after the moment referenced by the reset keyword (Section 3.4), and the reset keyword value may not be fixed nor constant.Subsequent requests might return a higher reset keyword value to limit concurrency or implement dynamic or adaptive throttling policies.

Which links to the reset section saying:

The client MUST NOT assume that all its service limit will be reset at the moment indicated by the reset keyword. The server MAY arbitrarily alter the reset keyword value between subsequent requests; for example, in case of resource saturation or to implement sliding window policies.

That being said, we are planning to revisit the caching mechanisms as part of https://github.com/arcjet/arcjet/issues/532 and should make sure we account for this.

[socket-security]

New and removed dependencies detected. Learn more about Socket for GitHub ↗︎

Package	New capabilities	Transitives	Size	Publisher

View full report↗︎

[blaine-arcjet]

@SocketSecurity ignore-all