Introduce aliases to make data model easier to use

[pcoccoli]

Is your feature request related to a problem? Please describe.
STIX patterning is not well known, and having to use things like src_ref.value can be confusing to new users. We've already "relaxed" the WHERE clause but we still use STIX object paths as attributes.

Describe the solution you'd like
We should have aliases for commonly used fields, e.g. src_addr for src_ref.value.

Describe alternatives you've considered
Alternatives could include using a different data model, but that's a much more disruptive change.

Additional context
Reference lists are not actually exposed at all right now, so they're almost lost entirely. An example is domain-name:resolves_to_refs. Aside from cumbersome naming, which is all aliases would help with, the reference lists would be difficult to work with. This is why firepit stores them in a separate table. This should probably be a separate issue.

[subbyte]

Fully agree we should make src_ref.value into something like src_addr as the first step before our own conceptual data model. I also find src_ref.value not friendly to new users.

I was wondering which naming rule to do for such convention. If we can make it explicit:

• We can put most names at https://kestrel.readthedocs.io/en/stable/language/eav.html#common-entities-and-attributes
• People can also follow the rule to map them from STIX to Kestrel if there are additional ones.

[pcoccoli]

I think any referenced property, e.g. parent_ref.pid or binary_ref.name could be aliased (as parent_pid and binary_name if we simply drop the _ref.).

[subbyte]

Yep. I am thinking if we can have a general rule for such alias naming. We can explicitly list all aliases Kestrel uses in entity doc, yet there could be automatic aliased ones if the rule applies.