[subscriptions] Fix for Validating URLs

[onelapahead]

We've observed a webhook subscription can be configured with URL which resolves an empty address (without throwing earlier errors):

panic: runtime error: index out of range [0] with length 0

goroutine 66 [running]:
github.com/hyperledger/firefly-ethconnect/internal/events.(*eventStream).isAddressUnsafe(0x11c4458, 0x1217e18)
	/kaleido-io/ethconnect/internal/events/eventstream.go:767 +0xd4

This is meant to treat this edge case then as an "unsafe address" so Ethconnect does not 1) panic and 2) the URL / hostname will be bubbled up as an error.

[codecov-commenter]

Codecov Report

Merging #239 (6c514c9) into main (111eb89) will increase coverage by 0.00%.
Report is 6 commits behind head on main.
The diff coverage is n/a.

❗ Current head 6c514c9 differs from pull request most recent head 2461f1e. Consider uploading reports for the commit 2461f1e to get more accurate results

@@           Coverage Diff           @@
##             main     #239   +/-   ##
=======================================
  Coverage   97.26%   97.26%           
=======================================
  Files          59       59           
  Lines        7521     7525    +4     
=======================================
+ Hits         7315     7319    +4     
  Misses        163      163           
  Partials       43       43           

see 2 files with indirect coverage changes

[onelapahead]

We determined this occurs when if the url of a subscription does not contain the protocol i.e. http:// or https://. It feels like we should possibly have validation for that to prevent this from occurring.

Or bc we are parsing an invalid URL and ignoring the error: https://github.com/hyperledger/firefly-ethconnect/blob/main/internal/events/webhooks.go#L57

[onelapahead]

Or bc we are parsing an invalid URL and ignoring the error: https://github.com/hyperledger/firefly-ethconnect/blob/main/internal/events/webhooks.go#L57

I've opted for handling this error as I believe this shouldn't be so optimistic since the subscription API does not validate the URL on creation / updates. Will defer adding such API validation for another time. This PR should be ready for review @peterbroadhurst @nguyer

[onelapahead]

Safeguard to prevent panics and instead treat an empty addr as unsafe

[onelapahead]

We now handle this error to late validate if what was provided on the subscription is in fact a URL and not something like a hostname or arbitrary string