Drop/Create Index Timestamping Race condition

[nacrooks]

1) Race condition
There was a race condition where dropping an index and recreate an index in close succession would cause timestamping to stop on a source.

2) Naming collision
This PR also fixes a case of duplicate naming if

1. there is a non materialized view v
2. there is a materialized view v1 that derives from v
3. we create an index on v

3) CHBench Load Generator

1. Ensures that customers of all countries are generated
2. Removes accidental correlation between item ids and supplier countries.

[wangandi]

are changes like these also intended to produce dates with a greater range of values than just the day that the demo is being run?

[quodlibetor]

for the metabase demo, which uses this, yes that is beneficial.

[nacrooks]

I've configured it to generate dates from 2000 to 2024.

[frankmcsherry]

Looks good to me! My understanding is limited, but the in-person explanation made things more clear.

[quodlibetor]

could you include what the meaning of the conversation with andi was? that commit message won't help us remember the rationale later.

[nacrooks]

What this PR doesn't solve:

Right now we lack a way to "identify" a source instantiation in a way that is 1) unique across dataflows 2) persists across crashes

We can achieve 1) by identifying a source instance with the pair (source_id, id of the first index that that view exports). Unfortunately, we cannot necessarily achieve 2): if we have two indices on a view i and ii (say respectively on column a and column b), we will recover the view with a different id than the one we created it with.

create view v1 as select * from aggdata;
create index i on v1(a);
[2020-02-10T18:13:32.783740Z  INFO coord/timestamp:266] Timestamping Source u2/u4 with Real Time Consistency
create index ii on v1(b);
drop index i ;
crash
recover
[2020-02-10T18:13:52.820311Z  INFO coord/timestamp:266] Timestamping Source u2/u5 with Real Time Consistency

This "bug" will have no effect on sources with BYO consistency. For "real-time" consistency, this will have the effect of treating the second "iteration" of the view as a "fresh" iteration with no prior timestamping information. This means before the crash, record 1 can be timestamped with t, and after the crash, it can be retimestamped with t'. It will not cause a crash or any data to be lost.
The only way that I can see to solve this is to associate a persistent dataflow id when we materialize the view and persist that dataflow id in the catalog.

[nacrooks]

The discussion with Andi was trying to identify a tuple that would refer uniquely to a given source instantiation. The pair (src_id.sid, first_export_id) is unique for a given run of Materialize, but not across runs if we create two indices and drop the first one only (see general comment in main PR)