Move FlowKey & FlowInfo to net and embed Flowkey in FlowInfo

[Fredi-raspall]

We want the flow info's to include the keys they are stored with in the flow-table.
This:

• avoids unnecessary re-building of keys in NFs, simplifies their code and reduces the possibility of errors.
• allows determining the key from the flow itself (to which packets have references).

To do that, however, we need to solve circular dependencies.

This PR:

1. moves the FlowKey out of the flow-entry (flow table) crate into the net crate.
2. moves the flow-info crate to net as well.
3. extends FlowInfo type to include a FlowKey.

• No functional difference should be observed by these changes
• Subsequent PRs will make use of those changes.

[mvachhar]

Why are we moving the flowkey stuff out of flow_table? Why would be bake it into net when it isn't necessarily universal (e.g., if we change the flow table implementation, maybe we change the flow key implementation too.

[Fredi-raspall]

Why are we moving the flowkey stuff out of flow_table? Why would be bake it into net when it isn't necessarily universal (e.g., if we change the flow table implementation, maybe we change the flow key implementation too.

Motivation
We want need the flow entries (FlowInfo) contain them. Right now there are 2 ways how NFs can access the flowInfos:

• if the key is known, via lookup()
• packets that matched a flowInfo have a reference to the flowInfo.

The problem is that, there's cases, where we may have a reference to a flowInfo but not know its key. Ofc, you may say, that if you have a reference to a flowInfo, that's because you have a packet and could build a key from it (because that should give you the key that allowed finding the flowinfo in the first place. However, there's cases where we can't do that. For instance, if you have a reference to a flow in the forward direction of port-forwarding, that flow may have a reference to the flow in the reverse direction. We can access that "related" flow, but right know we don't have ways to know what its key is.
So, embedding the key in the flowInfo seems like the right thing to do.

Problem
We can't embed flowkey in flowinfo for circular dependencies:

• net depends on flow-info (for the metadata reference to flowinfos)
• flow-entry (where flowkeys live) depends on net.
• we can't put flowkey in flowinfo as that would make flowinfo depend on flow-entry (terrible) and in turn depend on net.

So:

• we put flowkey in net. After all a key is just a collection of types from net
• we put flowinfo in net. Does not cause issues
• Flow-entry (the actual hash table of flows and lookup NF) depends on net (as it did already).

I agree that defining the flowkey outside of the flowtable is a bit odd. But, OTH, we're already doing that for the flow-info.

[mvachhar]

I hate these changes but I don't have a better solution to the circular dependencies that is safe for the near future, so approved.

[Fredi-raspall]

I hate these changes but I don't have a better solution to the circular dependencies that is safe for the near future, so approved.

I don't think it's that bad, other than enlarging net. Oth both Flow key and FlowInfo aren't that large.
Happy to explore alternatives later on.