Update UserIDs to Text

[FloorLamp]

Allows for user pubkeys to be used as IDs when https://github.com/dfinity-lab/dev/pull/806 is merged

[matthewhammer]

I have to admit that I don't fully understand this PR.

Why do you want the front end code to choose the internal IDs used in the backend?

It seems like we want a separate notion of public key, and a separate table mapping public keys to these internal IDs.

[matthewhammer]

What should happen in the case that registrarAddUser is called twice with the same userId?

Shouldn't that be an error?

Here, it will overwrite the old data with new data. I'm not sure that's what we want, is it?

[FloorLamp]

I believe that's what we want, right? A user/producer/retailer can update their info

[matthewhammer]

sure, updating information should be permitted, but that's a different operation than addUser, is it not?

[FloorLamp]

The client library would be adding an extra argument representing the userId, just like how it provides the console log function.

Agreed, a separate table makes more sense

[matthewhammer]

This PR changes all internal IDs from numbers to text. However, I don't think that we want to do that now, or in the future.

It also completely breaks the unique ID generation code, which used to increment internal counters (now replaced with text and no counter).

[matthewhammer]

To see evidence of the brokenness, e.g., check out the output in _out/ProduceExchange.out:

Exchange setup
====================================
- Truck type count: 5
- Region count: 5
- Produce count: 5
- Producer count: 5
- Transporter count: 5
- Retailer count: 5
- Inventory@time1 count: 9
- Inventory@time2 count: 7
- Inventory@time3 count: 7
- Route count: 12

Retailer queries
====================================

Retailer rra sends `retailerQueryAll`
------------------------------------
- retailer is located in region 2, and
- is accessible via routes from 2 production regions.
prelude.as:23.23-23.35: execution error, assertion failure

[matthewhammer]

The larger design question here is this one: Who should choose the internal IDs used in the PX?

I argue that the PX backend code, not any user, should be choosing these IDs. This PR makes the opposite assumption, which feels very problematic to me.

E.g., when I go to github and create a PR, I don't get to choose the number for this PR; github just assigns the next one using some counter that it controls. The PX should be following a protocol like this one, which seems fairly standard, and well-understood.

[FloorLamp]

Yup, that makes sense. I'll revert and add a new table for public keys

[matthewhammer]

Rather than work on this branch directly, I made a new PR inspired directly by this one.

[matthewhammer]

Oops; the specific buggy behavior that I attributed to this PR was actually from something that I did earlier, now fixed here: 8025d57

Apologies @FloorLamp for mistakenly blaming this PR in my comments above.

In any case, I think the new PR still represents what we want to do now.