feat: Asset cleanup

[k-anshul]

closes #5144

[begelundmuller]

Can just be called Assets (e.g. like it's Email, not EmailClient, etc.)

[k-anshul]

I can change it here to keep it consistent with other variable names.
Overall I am skeptical on this practice.
One argument given by Rob Pike to use capital names for exported variable in golang is that I don't need to look at variable's definition to determine whether its an exported or local. I would extend the argument to here that I don't need to look at the variable definition to determine what it does. Sadly Email or AI provides no such information.
The variable names should be somewhat self explanatory when used in such bigger contexts like Service.

[begelundmuller]

I think you may have misunderstood that argument. See the section on variable names in the style guide. It states:

Omit types and type-like words from most variable names.

With the argument that:

The compiler always knows the type of a variable, and in most cases it is also clear to the reader what type a variable is by how it is used.

IMO it makes sense and is in line with ideas of domain driven design. Basically, you name things for what they are used for, not their implementation details. In this case, it's a variable that gives you access to Assets – whether it's a bucket, or a directory handle, or an interface, does not need to be reflected in the name unless there is ambiguity.

[k-anshul]

Basically, you name things for what they are used for, not their implementation details.

AssetHandle or AssetsBucket is not an implementation detail IMO. AssetsGCSHandle would be.
It gives a subtle hint about what they are used for.
With just Assets I can't possible guess what it is used for. Is it a cache ?