RFC: initial drainable filter chain

[lambdai]

No description provided.

[lambdai]

@PiotrSikora Does this abstraction work?

[lambdai]

Self answer:
Draining the filter chains by Network::FilterChain pointer restricts the implementation at LDS/FCDS client at master thread
Draining the filter chains by name is error prone: there might be ABA problem, say update-drain-create
Draining the filter chains by tag(incremental id) might be the easy solution.
CC @htuch WDYT?

[lambdai]

using FilterChainTag = uint64_t;
std::unordered_map<FilterChainTag, ConnectionGroup> connection_groups_;
Group& ActiveTcpListener::findGroupByFilterChain(FilterChain * chain) {
  return connection_groups_[chain->filterchainTag()]; // omit how the Group is constructed.
};

[htuch]

@silentdai why do you need to do identify the filter chain, don't you know which one it is during an LDS update, where you have the LDS DiscoveryResponse on-hand and you are comparing against the active filter chains? There should be no racing at that point.

I suggest syncing with @mattklein123 on the design for filter chain draining, I'm sure there are a bunch of nuances here, and it's been a long time since I reviewed the LDS work.