Remove bounds on shadow queue size

[kstribrnAmzn]

Description of changes:
Removes the default shadow queue size limit
of 1024 shadows.

Misc changes:

• Updates to upload-artifact v4 as v3 is deprecated
• Updates nucleus dependency version to allow for local builds on M-series macs

Why is this change necessary:
By removing bounds on the shadow queue size
users can now have more than 1024 shadows. 'Take'
operation behaviors remain the same however 'Put'
operations will no longer block as waiting for
space is not a thing.

How was this change tested:
Figuring this out now

Any additional information or context required to review the change:
The Shadow-Manager has a queue for device shadows. This queue is limited to 1024 shadows by default (but dynamically sized when <1024). This hard limit will prevent customers from having > 1024 shadows. By removing this limit we allow more shadows with likely minimal to no effect for most customers.

For customers with > 1024 shadows this will fix blocking issues which will prevent the device from updating at the cost of additional memory.

Issue #, if available:
V1876603400

Checklist:

• Updated the README if applicable
• Updated or added new unit tests
• Updated or added new integration tests
• If your code makes a remote network call, it was tested with a proxy

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[github-actions]

Unit Tests Coverage Report

File	Coverage	Lines	Branches
All files	83%	88%	77%	✅

Minimum allowed coverage is 65%

Generated by 🐒 cobertura-action against 24a9987

[github-actions]

Integration Tests Coverage Report

File	Coverage	Lines	Branches
All files	73%	76%	69%	✅

Minimum allowed coverage is 45%

Generated by 🐒 cobertura-action against 24a9987

[alter-mage]

I understand that we will never reach this situation, but how are we handling the case where java throws an out of memory error when shadow manager tries to put a new request to the requests map?

[kstribrnAmzn]

Never say never. You're right in the fact that we could hit this case. I'll take a look at the code tomorrow and try to add in a try-catch (or multiple) to account for this. The most sensible place I can see is on the put call as the map should resize when inserting an element causes it to go above load factor.

[kstribrnAmzn]

Closing in favor of #210.