Turns out, this is the wrong approach. It's still useful code
because it's a direct method for passing strings that doesn't
rely on rkyv (so it could potentially be more efficient for
very efficiency-oriented applications).

But I think in the end, after writing this and seeing the errors
that come from it, I think we should just abandon String<N> altogether
because it doesn't get us anything.

this triggers a whole lotta changes....

minor cleanup because the warning is distracting from chasing
down all the other warnings

split into a couple commits for ease of committing

split into multiple commits for easier committing

split into multiple commits for easier committing

split into multiple commits for easier committing

core xous services cluster

more regex results

codegenerator fixes

includes some light touch-up to the API to clean up a consequence
of String not being copy-able anymore

some idioms are improved with String, this cleans up a bit of code
in addition to the search/replace

Rust can't tell how to cast some u32_le into u32/usize automatically
due to confusion with the num_derive trait, so we have to explicitly
specify a chain of typecasts to clean up the conflict with the
new rkyv

xous_ipc::<String> had a clear-volatile() API for zeroizing
sensitive strings.

This is now missing in String, so it has been manually implemented
here by casting the String to a slice-u8 and then iterating
through it using raw pointers and volatile writes with a compiler
barrier to hopefully avoid all of the landmines I know of for
zeroizing a string...

commit is called out separately because this one is one of the
more "dangerous" security-related changes in the API migration.

There isn't a simple regex to deal with the loss of Copy when
deprecating xous_ipc, so this has to be a manual pass.

Losing the copy trait means (maybe) some loss of efficiency
in the API because we have to clone some structures instead
of copying them, although, I think actually what might have
been happening under the hood anyways is the copy was implemented
as a clone-under-the-hood for the xous-ipc.

Either way, this happens in the high level management structures
for modals, so it's not the end of the world to incur a clone
on the description of the structures -- we'd have to pay
more attention if this happened e.g. at the pixel shuffling
level, but a few UI strings at human-interaction rates
isn't going to kill us.

The original loop takes advantage of the copy-trait that is
no longer available. I think the intent of the loop was to
mutate a field within the copy through each iteration so you
can update the prompt to handle field validations that failed
without re-allocating the ManagedPromtWithTextResponse structure.

This has been rewritten to alloc that each iteration to avoid
the borrow error, and instead the `prompt` itself is a string
that's initialized with the initial prompt message and is updated
on each iteration if the form validation fails.

@gsora git seems to say you wrote this code, maybe I could use
your help to review this patch.

note for more review by bunnie down the road to make sure
that I have not changed any behaviors accidentally in fixing
the loss of Copy on a core structure

a bunch of code has to be re-formatted because spacing changed
and we have a strict formatting rule

a bunch of lines are shorter or different length now which
triggers a mandatory reformat. this patch cleans that up,
so that going forward the manual rework patches are clearer and
not tied up with formatting patches.

I think this is safe to do because no strings can be directly
serialized into the PDDB's structures. The place to check for
this is inside the backend/ directory. For example, `DictName`
is where the name field is serialized into a structure that
goes onto the disk. It's explicitly length-checked.

What this means is that we could have calls into the pddb crate
with invalid length strings, however, if you check the lib
implementation, all of the APIs also pre-flight the length of
arguments to ensure they fit into the destination string.

So mostly what we're losing is the constraints on the intermediate
IPC representation, but the length is still checked on either side.

…e done.

And I did it! and it's now fixed.

I was using xous-ipc String to make a fixed-length string in a
structure that's not strictly an IPC structure.

The solution to this is to just implement a fixed length string
directly.

the into/from inner methods are useful for using the Buffer
abstraction as a way to invoke rkyv on a structure to serialize
it and then manipulate the serialized data directly

also some more regex fixup

the implementation relied on a quirk of xous-ipc where the message
ID is 0 for string send/receives. This cleans it up so that the API
is transparent and consistent with other API calls in the system.

@nworbnhoj would love it if you could have a look at
the implementation and let me know if I've ported this correctly.

I think what was going on is you were using rkyv to serialize
a structure to the PDDB. I've just updated the ser/de to use
the latest `alloc` API (which is much simpler than the API used
in xous-ipc because it is no-alloc).

I'll try and run some tests that involve the TLS crate too down
the road under the theory that it would suss out any porting
errors.

not doing a reformat of the entire project to match
nightly formatting changes, but capturing the published
crates so we can maybe save a version bump later on to get
the project clean.

prior use of `rkyv` reserves two bytes to record `pos` pre-pended
to the rkyv record

the new rkyv works without having to do that because it indexes
the rkyv data off the end of the stored records. Thus, all you
need to know is the total length of the byte slice that stores
the serialized data. This is available as the return argument
when you read a PDDB key, so we don't have to explicitly store it
anymore.

Before xous-ipc's fixed-length string guaranteed this thing
fit into a single page. Now, we can send potentially unbounded
amounts of text between servers.

I don't think it makes sense to send more than a few k of text to
render on the screen at once, given our screen sizes, so I've added
a patch that truncates the text to the previous length that things
would truncate to.

The behavior is the same as before, except that you will
over-allocate memory on the heap in the sending process
as you shove more string data into a TextView than can be rendered.
Previously, the TextView would just truncate the data and discard
the data.

The truncation happens at the point where you try to hand the
record off to another process, so, one could in theory try
to make this recoverable by adding a layer that splits the
textview into more manageable chunks or pages the data, but that
is an exercise for another day.

we don't have to pass a "size" field anymore; since we're end-offset
from pos, just pass pos and use that to chain records.

this allows us to handle the error. probably should propagate
on to xous-ipc

this allows for more graceful error handling in case of
serialization failures