Fix/revert on already set values

[julien-devatom]

• Ive defined 2 errors since I want to distinguish the cases on submission of the pending root. Is it reverting due to the current pending root or the current root?

• I'm not convinced about the error names, open to suggestion 😆

• cantina issue

[QGarchery]

Agree that it should revert on already set values, but I think that it would cleaner with #100

[QGarchery]

This makes me wonder if we should make the revert explicit when the URD has already been deployed, by adding a check in the UrdFactory. I think no because it would be an edge case and also it would not be kind of awkward to do

[Rubilmax]

@oumar-fall actually stumbled upon this issue today

[MerlinEgalite]

@QGarchery maybe you can update this PR so I can trigger spearbit

[Rubilmax]

@oumar-fall actually stumbled upon this issue today

[StErMi]

I'm not very sure how I feel about the submitRoot and setRoot implementation because the owner/updater can still call the submitRoot when the timelock == 0 and it would be immediately "acceptable".

The updater needs to always check which is the timelock value to know if it needs to call setRoot or submitRoot.

[Rubilmax]

I'm not very sure how I feel about the submitRoot and setRoot implementation because the owner/updater can still call the submitRoot when the timelock == 0 and it would be immediately "acceptable".

The updater needs to always check which is the timelock value to know if it needs to call setRoot or submitRoot.

It doesn't look like an issue to me: the owner/updater would in this case have to also call acceptRoot right after
The benefit of this implementation is that each function has a single responsibility (submitRoot: manage pending root, setRoot: manage root)

[QGarchery]

The updater needs to always check which is the timelock value to know if it needs to call setRoot or submitRoot.

The updater already had to check the timelock value because was used to discriminate whether it is possible to update instantly or not.
I think it's just better now because if the updater wants to update the root instantly, he can do so by calling setRoot. If the timelock is not 0 it would revert instead of failing silently and submitting a pending value