Remove generics from the action type, as it's not only bad for asserting every action you create, it's bad for binary size (every Entry * 2 for monomorphization)

This is a tracking issue for the metadata feature

What is it?

The metadata feature will allow the Gateway to hold metadata about each struct within the table, for comparison and updating tables

How does it work?

This will be a feature gated item, as it does a lot of things with tables
First off, the "metadata" string will be restricted, and any items that attempt to use it will result in a runtime error
The Entry trait will have a new Default bound, and any Entry that wishes to use this should have a Default implementation that matches any default values they wish to set
Any time a table is created, a single entry will be inserted, that has the key "metadata" and the value should be the Default value
Any attempts to modify or delete the "metadata" entry shall result in a runtime error.

C/R/U/DOperation and Table/EntryTarget should have their Default Implementations removed, as they are just marker types and not meant to be constructed in any meaningful way

My idea is to split FS into its own crate and as a struct instead of a trait, with multiple different transcoders (think JsonTranscoder, TomlPrettyTranscoder, etc.), this design cuts down on features and bloat, and allows us to move all the backends into its own separate crate

This should also be based on the flock.rs implementation in cargo

This crate should start using the std::sync module to help with ensuring atomic operations happen correctly, especially as it grows more complex

This should allow users to specify which atomic ordering method to use, either with the Ordering enum provided in std::sync or something similar, and be passed to the Gateway, any other inner workings should not be revealed to the user

Should use an Action struct to easily allow for CRUD operations (Create, Read, Update, and Delete)

Struct should hold table and struct metadata, an ActionType enum that tells the Action what CRUD action it's performing, as well as a generic for the type, , but not references to the table, database, or backend

Any errors reported should be done in run-based method (name subject to change), not before unless it's unavoidable

This shouldn't be wrapped in an Arc, anything that needs to use this and pass it between threads should wrap it itself, or rework it's database structure

Database methods (get, delete, create, update, etc.) should be deprecated, and may be added later under a feature flag

This will require a minor release (as it's before 1.0) and should come with tests

Actions will mark the release of 0.4, and after any bug fixes and changes to the API (if any), Database, DbRef, and other associated methods and types will be removed with the release of 0.5, users wishing to keep using the database api should stick to the 0.4 release, as the db methods most likely won't be making a return unless a high amount of community support wants them

Currently the Key trait and starchart derive macro return owned keys from a reference struct, which means only Copyable keys are usable, which isn't the usecase we want

Several fixes are needed for actions

• on directive doesn't need to be specific anymore
• coverage doesn't need to be ram with just one thread, as the plan is to use the file name for each backend testing

Allow errors to be incremental, so we can get to the source

Unit tests should be provided to be around 60% across the entire crate, and 100% in each provider (which at one point will not be the entire crate, so more should be added initially)

Coverage is measured with codecov.io

Simplify the generics in Actions until Rust-Analyzer is able to properly infer them

Should include basic usage, how the fs backend works (it uses tokio for example) the dual license thing, and more

Need to use atomic file operations for fs based backends, as tokio does not automatically use atomics

With the clippy ice being resolved, we can finally reenable this lint

The metadata feature seems to be causing issues, releasing a patch version to compile error until it's fixed

run benchmarks anywhere there are iter and into_iter calls, and make sure it doesn't cause data race issues with atomics