NOISSUE - Migrate gocoap library from v2 to v3.3

[felixgateru]

What type of PR is this?

This is a feature because it migrates the version of the coap library from v2 to v3.3

What does this do?

• Migrates the plg-dev\go-coap library from v2 to v3.3
• Improves CLI by using spf13/cobra

Which issue(s) does this PR fix/relate to?

Resolves https://github.com/absmach/magistrala/issues/2203

Have you included tests for your changes?

Yes, I have included tests for my changes.

Did you document any new/modified feature?

No,

Notes

No,

[arvindh123]

Since we are supporting all functions of coap , we should have test case for all methods with all options with some publicly available coap sever like https://coap.me/crawl/coap://coap.me

[arvindh123]

Suggestion for KeepClient Connection Alive https://github.com/1998-felix/coap-cli/blob/d4705eed8646741d28d1fd7a2aac0bc9bb987368/coap/client.go#L29-L36

func New(addr string) (Client, error) {
	c, err := udp.Dial(addr, options.WithKeepAlive(10, 60*time.Second, func(cc *client.Conn) { fmt.Println(cc.Ping(cc.Context())) }))
	if err != nil {
		log.Fatalf("Error dialing: %v", err)
	}

	return Client{conn: c}, nil
}

In additonal , It will be great if we provide flags to set have keep Alive time out in client

If flag is not available defaults to 60 seconds.

If KeepAlive Time flag is 0 then it should not add KeepAlive function during connect.

[dborovcanin]

Please resolve conflicts.

[arvindh123]

Server disconnection idle client leads to new problem
The client doesn't know the disconnection, and client again send disconnection request to server
So we are getting error in server like {"time":"2024-05-16T10:17:46.594334142Z","level":"WARN","msg":"Unsubscribe failed to complete successfully","duration":"31.172803ms","channel_id":"dff59205-90d6-430d-9903-a611cd401bb3","error":"not subscribed"}

[dborovcanin]

Server disconnection idle client leads to new problem The client doesn't know the disconnection, and client again send disconnection request to server So we are getting error in server like {"time":"2024-05-16T10:17:46.594334142Z","level":"WARN","msg":"Unsubscribe failed to complete successfully","duration":"31.172803ms","channel_id":"dff59205-90d6-430d-9903-a611cd401bb3","error":"not subscribed"}

It looks like the problem is that the subscribed client isn't aware of the broken subscription, which makes sense due to the connectionless nature of the underlying UDP. We can merge this one, but @arvindh123 please open a ticket to remind us to double-check this.