Fix `assets` SQL table unique constrinat

[ffranr]

The assets SQL table's unique constraint is ineffective (it's a no-op). It doesn't do what we intend it to do.

The current unique constraint is on the fields:

asset_id, genesis_id, script_key_id

but asset_id is the table's primary key integer and not the asset ID byte array. This means that each row is unique and that duplicate assets can be inserted into the table.

We add a unique constraint index with the following fields to the table:

anchor_utxo_id, genesis_id, script_key_id

With this new constraint we should not be able to add duplicate assets into the table.

Adding the new constraint will mean deleting rows from the assets table which violate this new constraint.

Another change that follows naturally from this modification is to change the InsertNewAsset SQL statement into an upsert.

This issue has caused this bug https://github.com/lightninglabs/taproot-assets/issues/665 but another solution has now addressed that bug.

PR https://github.com/lightninglabs/taproot-assets/pull/684 is an attempt at fixing this issue.

[dstadulis]

I had started writing an issue for these needs. Feel free to edit or lift any relevant elements.

Issue title:

Test duplicate address receive flow + DB uniqueness

Description:

This test will ensure that if a client tries to send to two duplicate addresses (say in the same transfer), that the daemon throw an error, we'll want to note if it gets clobbered in an internal map. It's important to make sure this is tested to avoid any potential issues with transactions being processed incorrectly. The unit tests should cover the scenarios:

1. Global/DB uniqueness: Test the outpoint + assetID + scriptKey are indeed globally unique and sufficient to ensure unique DB location and compatible with address reuse.

2. Batch collision: internalKey + assetID + scriptKey don't collide within a batch.

3. Outpoint collision: assetID + scriptKey don't collide within an outpoint.

4. Duplicate Sends: Test should also include a scenario where a client sends to multiple different addresses, but one of them is duplicated - to test if only the duplicates get rejected or if all transactions fail due to an error.

[ffranr]

~~We should complete issue https://github.com/lightninglabs/taproot-assets/issues/694 before addressing this issue.~~ #691 is ready

[gijswijs]

Removing the old constraint is still an open issue #967