there is still a lot of potential work that needs to be on this front.
1. supporting atomics on create actions.
2. supporting atomics in upserts (this one may actually be much easier than the first one, for postgres specifically, due to ecto implementation details)
3. discovering places atomics can be more nicely integrated into existing changes, validations, policies
Will document this in a separate PR. The broad strokes are this:
1. to load through an attribtue, `load(attribute: [:nested: :stuff])`
2. to load through a calculation, `load(calculation: {:%{...input}, nested: :stuff})`
3. union types support loading through them, and is done first by keying by the type name, i.e: `load(union: [type_name: [nested: :stuff])`.
4. union types support specifying a load statement for all types with `load(union: [*: [nested: :stuff]])`
Calculation loading is complex because different calculations can
depend on differently parameterized things. FOr example:
```elixir
def load(_, _, _), do: [foo: %{arg: 1}]
def load(_, _, _), do: [foo: %{arg: 2}]
```
The previous naive implementation would simply merge all of the calculation loads, which naturally would not work. Now we ensure that we load each requirement in isolation.
improvement: more comprehensively remove unnecessary clauses
fix: resolve issue with `authorize_unless` and filter checks
improvement: prevent changing attributes and arguments after action validation
We allow for these changes inside of `before_action` calls, but otherwise
require that `force_change_attribute` is used, for example. This prevents
accidentally validating a changeset and then changing an attribute.
Previously, only a few specific changes supported using `arg/1` or `context/1`
in their options. Now, those templates can be used in any change options,
built-in or not.
improvement: add more ergonomic manual action definitions.
The old method will likely be deprecated some time in the future (there is no rush really, they both work).
This helps with things like https://github.com/ash-project/ash_phoenix/issues/57
which involve rendering the relationship value after editing it. Retaining
the order allows direct reuse without any gymnastics
