Update to idiomatic rust

[berendsliedrecht]

Dependent on #25

• Resolved some issues that clippy was giving.
• renamed some functions to not make them collide with functions from std

Also fixed some small stuff from indy-utils, just to make clippy be quiet.

Work funded by the Government of Ontario.

[andrewwhitehead]

Not sure why one of these is an Into<SchemaId> and the other a &str?

[andrewwhitehead]

Also I don't love Into<SchemaId> because it skips validation (can't return an Err).

[berendsliedrecht]

My idea was to internally use the SchemaId and for the API we use impl Into<T>. when we get the schema_id we call it like so:

fn test(s: impl Into<SchemaId>) -> Result<Any> {
  let s = schema_id.into().validate()?;
}

This way we always validate when the value comes in, but we do not require the user to cast every string into a SchemaId.

[berendsliedrecht]

It is incorrect that it is inconsistent, this should be fixed.

[andrewwhitehead]

It does seem more idiomatic to me for it to be a validating wrapper, ie. validation is performed when it is constructed rather than potentially being missed later. The struct(s) could have a const fn new_unchecked(value: &str) for skipping validation in tests or const contexts. (Actually, supporting const would limit the internal representation options right now)

[berendsliedrecht]

Agreed. I created a validated_new() (did not see this comment before that) which does what your implementation of new would do. I think that validating with new is better, as it will validate by default.

I also left a comment at #25 where I propose TryInto instead of Into, which makes a lot of sense here IMO. If that seems okay with you, I can create a follow up PR where Into will be changed to TryInto.

[berendsliedrecht]

Implemented new with validation in #25 .

[berendsliedrecht]

I assume we do not have to call drop here ourselves, right?

[berendsliedrecht]

I converted all the Into<T> to TryInto<T> but a downside now is that if we request Option<impl Into<SchemaId>, and we want to supply None, we MUST do it like this: None::<SchemaId> which I do not like. We only do this for the rev_reg_def_id, but it is a weird inconsistency. Not too sure what the right direction is here.